Le Plan d’Occupation des Sols (POS) du système d’information divise. Certains le considèrent comme un pilier de l’urbanisation des SI, indispensable pour structurer la cartographie fonctionnelle, organiser les domaines métier et garder une vision globale de l’architecture du système d’information. Dans cette approche, le POS apporte une vue transverse qui permet d’aligner les acteurs, les activités et l’organisation autour d’un référentiel commun. D’autres le perçoivent comme un outil trop conceptuel, issu d’un urbanisme plus rigide, difficile à concilier avec des projets agiles, des cycles courts et des architectures applicatives modernes.
Cette opposition est révélatrice. Sans plan fonctionnel structuré, le système d’information dérive vite vers un “plat de spaghettis” : multiplication des applications, duplication des données, perte de maîtrise des flux, complexité croissante des processus métier. L’architecture applicative devient illisible, chaque projet ajoute une couche, et la cohérence globale du SI se fragilise. Mais à l’inverse, un POS mal utilisé peut devenir une couche théorique déconnectée des réalités terrain.
En pratique, le sujet n’est pas de savoir si le POS est obsolète. Il ne l’est pas. Il s’est transformé. Son découpage en zones, quartiers et blocs fonctionnels reste pleinement pertinent dans des architectures modernes basées sur les microservices, les API, le cloud ou encore les plateformes data et IA. Chaque service applicatif ou composant tend aujourd’hui à devenir un bloc autonome, ce qui rapproche directement les pratiques actuelles des principes du POS.
On ne parle plus d’un plan d’urbanisme figé, mais d’une démarche structurée, incrémentale, qui s’adapte en continu aux évolutions des systèmes, des processus et de la stratégie d’entreprise.
Dans cet article, je vais vous montrer comment utiliser le POS pour structurer la cartographie fonctionnelle de votre système d’information sans freiner sa capacité d’évolution.
Le POS fonctionnel : définition, structure et rôle dans le système d’information
Le Plan d’Occupation des Sols (POS) du système d’information est avant tout un outil de structuration. Il permet de représenter le système non pas à travers ses applications ou ses choix techniques, mais à travers ses fonctions métier, ses services et ses données. C’est une vue fonctionnelle de référence, qui apporte un cadre stable pour comprendre, organiser et faire évoluer le système d’information.
On ne part plus des briques applicatives existantes, mais des besoins métier qu’elles doivent couvrir. Le POS devient une cartographie fonctionnelle indépendante de l’architecture technique, qui permet de structurer le système dans le temps.
Pour cela, il repose sur un découpage en zones, quartiers et blocs fonctionnels :
- Les zones fonctionnelles: elles correspondent aux grands domaines du système d’information et structurent la cartographie globale. On distingue généralement cinq grands domaines :
- Opération : les fonctions cœur de métier directement liées à l’activité de l’entreprise
- Pilotage & contrôle : les fonctions de suivi, reporting, audit et prise de décision
- Ressources & support : les fonctions support comme les RH, la finance ou l’IT
- Échange : les interactions avec les acteurs internes et externes (clients, partenaires, systèmes)
- Données transverses : les données partagées et les référentiels communs à plusieurs domaines
- Les quartiers fonctionnels : sous-ensembles cohérents liés à un périmètre métier ou à des données.
- Les blocs fonctionnels : unité de base du POS, regroupant fonctionnalités, données et règles de gestion.
Ce découpage ne sert pas uniquement à représenter le SI. Il structure la manière dont il fonctionne et dont il évolue.
En posant des blocs fonctionnels, on pose aussi des règles. On définit où se trouvent les données, qui en est responsable, comment les flux circulent entre les différentes parties du système. Cela permet d’éviter des situations très fréquentes où plusieurs applications implémentent les mêmes fonctions ou manipulent les mêmes données sans coordination.
Le POS permet aussi de faire le lien entre conception fonctionnelle et architecture applicative. Les applications viennent s’adosser à des blocs existants plutôt que de recréer de nouveaux périmètres fonctionnels.
Dans la pratique, c’est un levier concret pour garder de la cohérence dans un système qui évolue en permanence. Chaque évolution peut être positionnée dans le POS, ce qui permet d’éviter les chevauchements.
Le Plan d’Occupation des Sols comme outil de pilotage du système d’information
Une fois la structure en place, le POS ne sert plus seulement à représenter le système d’information. Il devient un véritable outil de pilotage, au cœur d’une démarche d’urbanisation du système alignée avec la stratégie de l’entreprise.
Dès qu’on passe par le POS, on change de grille de lecture. On ne regarde plus des outils, mais des fonctions, des services et des responsabilités.
Le POS permet concrètement de :
- rendre le système d’information lisible, en proposant une représentation structurée du patrimoine applicatif et des fonctions métier, là où les outils fragmentent la compréhension ;
- maîtriser la complexité, en identifiant les redondances de fonctionnalités, les doublons de données et les incohérences entre processus, souvent invisibles dans une approche purement technique ;
- piloter le SI à un niveau pertinent, en projetant des indicateurs (coûts, nombre d’applications, obsolescence, valeur métier) sur les zones, quartiers et blocs fonctionnels ;
- structurer les décisions et les projets, en positionnant chaque nouveau besoin dans une carte existante, plutôt que d’ajouter une couche applicative sans cohérence globale ;
- accompagner l’évolution du système, en s’appuyant sur des blocs applicatifs et fonctionnels autonomes, ce qui facilite la transformation digitale et la mise en œuvre progressive des changements.
À partir du moment où cette cartographie devient un référentiel partagé, les échanges évoluent. On ne parle plus uniquement d’outils, mais de périmètres fonctionnels et de valeur métier. Le POS devient un support d’analyse et d’aide à la décision.
Au fond, ce que je cherche à faire avec un POS, ce n’est pas de dessiner un système parfait. C’est de poser un cadre suffisamment solide pour que le système reste cohérent, même quand il bouge dans tous les sens.
Le POS comme cadre de conception : passer d’une logique projet à une logique système
À partir du moment où le POS devient un référentiel partagé, il ne sert plus seulement à piloter le système. Il commence à structurer la démarche de conception dans une logique d’urbanisation du système d’information, alignée avec la vision métier et la stratégie de l’entreprise.
Dans beaucoup d’organisations, la conception reste encore très orientée projet. On traite un besoin, on choisit une solution applicative ou technique, puis on passe au suivant. Le résultat, on le connaît : un système qui s’empile sans véritable architecture fonctionnelle.
Le POS vient introduire une logique différente. Il impose de raisonner à l’échelle du système, en s’appuyant sur une carte fonctionnelle structurée.
Dans la pratique, ça change la manière de concevoir. On ne se demande plus uniquement comment répondre à un besoin métier, mais comment il s’intègre dans l’architecture fonctionnelle existante :
- est-ce que la fonctionnalité existe déjà dans un autre secteur fonctionnel du système ?
- dans quel bloc ou module du POS elle doit être positionnée ?
- est-ce qu’on enrichit un composant existant ou est-ce qu’on crée une nouvelle capacité métier ?
- comment les flux de données vont circuler entre les zones, les quartiers et les différents niveaux du système ?
Ce type de raisonnement permet de structurer la conception dès l’amont des projets, en tenant compte du contexte global, des processus métier et des interactions entre entités du système.
On reproche souvent au POS d’être éloigné du terrain. En réalité, c’est dans cette phase qu’il prend toute sa valeur. Il structure le découpage des fonctionnalités et la circulation des flux de données.
La structure du POS organise la répartition des fonctionnalités, la gestion des données et les échanges entre services. Le découpage en blocs fonctionnels est proche de la logique des microservices : chaque bloc devient une unité autonome avec ses données et ses responsabilités. Les flux anticipent les problématiques d’intégration via API ou événements.
Le lien avec l’applicatif est direct : mapping des applications, choix build vs buy vs SaaS, structuration des données. Lorsque ce cadre n’est pas respecté, les dérives apparaissent rapidement : duplication des données, incohérences, perte de maîtrise du système.
Il n’y a pas d’incompatibilité avec l’agilité. Le POS apporte une vision structurée qui permet de faire évoluer le système en continu. On ne conçoit plus un ensemble de solutions indépendantes, mais un système organisé.
Comment mettre en place un POS fonctionnel dans un système d’information
Sur le papier, le POS est assez simple à comprendre. Dans la pratique, sa mise en œuvre est souvent plus délicate. Non pas parce que la démarche est complexe, mais parce qu’elle demande de changer de logique. L’enjeu est de construire une représentation utile, capable d’accompagner les projets et de structurer les décisions.
C’est pour ça que les démarches qui fonctionnent sont rarement les plus ambitieuses au départ. Ce sont celles qui avancent par étapes, en partant du métier, en structurant progressivement la carte du système et en l’enrichissant au fil des usages.
Partir du métier avant de partir des applications
La première erreur, c’est de commencer par la cartographie applicative. Un POS ne se construit pas à partir des outils existants, mais à partir des besoins métier, des processus, des activités et des échanges qui structurent réellement l’entreprise. C’est ce travail d’analyse qui permet de poser une première vue métier cohérente et d’éviter de calquer le futur référentiel sur les défauts de l’existant.
Définir les grandes zones fonctionnelles du système
Une fois cette lecture métier posée, il faut organiser le système en grands domaines. C’est là qu’intervient le découpage en zones fonctionnelles, qui permet de structurer la carte du SI à un niveau macro. On retrouve généralement les grands ensembles classiques du POS : opération, pilotage & contrôle, ressources & support, échange, données transverses. À ce stade, l’objectif n’est pas d’entrer dans tous les détails, mais de construire une structure lisible, stable et partagée.
Affiner la cartographie avec les quartiers et les blocs fonctionnels
Le travail peut ensuite descendre d’un niveau. Chaque zone est affinée en quartiers, puis en blocs fonctionnels. C’est à cette étape que le POS devient réellement exploitable. On précise les périmètres, on regroupe les fonctionnalités cohérentes, on identifie les données manipulées et on clarifie les responsabilités associées.
C’est aussi ici que certaines règles simples structurent la suite : une donnée appartient à un seul bloc, chaque bloc est autonome avec une cohérence forte et un couplage faible, et les échanges entre blocs sont maîtrisés. Le POS ne décrit pas une implémentation, il pose un cadre.
Rattacher l’existant à la structure cible
Un POS n’a de valeur que s’il permet de lire le système réel. Il faut donc rattacher progressivement les applications, les composants, les flux et les principaux objets de gestion à cette structure fonctionnelle. Ce rapprochement entre la cartographie cible et le patrimoine applicatif existant permet d’identifier les recouvrements, les manques, les zones de complexité et les incohérences. C’est souvent à cette étape que le POS devient un véritable outil d’analyse.
Impliquer les bons acteurs dans la démarche
La mise en place d’un POS n’est pas un exercice solitaire d’architecte. Elle suppose une lecture croisée entre métier, IT, organisation et parfois partenaires externes. Si la démarche reste enfermée dans un cercle trop technique, elle perd immédiatement de sa valeur. Pour qu’un POS soit utile, il doit devenir un référentiel partagé, compris par les équipes qui conçoivent, exploitent et font évoluer le système d’information.
Faire du POS un référentiel vivant
Le dernier point est probablement le plus important. Un POS ne doit pas être conçu comme un livrable figé ou comme un document de plus dans un outil de cartographie. Il doit vivre dans le temps, être mis à jour au fil des projets, des évolutions d’organisation et des nouveaux usages. Les démarches qui fonctionnent sont rarement celles qui cherchent l’exhaustivité immédiate. Ce sont celles qui acceptent de construire un cadre utile, puis de l’enrichir progressivement à mesure que le système évolue.
Conclusion : le POS, un outil souvent mal compris… mais toujours structurant
Le POS reste un objet paradoxal. Il est souvent perçu comme un outil théorique, parfois daté, éloigné des réalités opérationnelles ou cantonné à des contenus de type blog, formation ou page de cartographie SI peu exploités dans les projets. Pourtant, dans la pratique, ce n’est pas le concept qui pose problème, mais la manière dont il est utilisé. Lorsqu’il devient un simple fond de carte figé, oublié dans un référentiel ou jamais mis à jour, il perd immédiatement sa valeur. À l’inverse,lorsqu’il est utilisé comme un outil vivant, intégré aux démarches d’urbanisation fonctionnelle, il devient un véritable levier de compréhension et de pilotage.
Le contexte actuel renforce clairement cette utilité. Avec la transformation des systèmes d’information, la généralisation des architectures distribuées, la multiplication des services SaaS, des API et des flux de données, le SI n’est plus un simple support. Les organisations doivent composer avec des systèmes distribués, des flux de données en temps réel, des interactions multiples entre métiers, partenaires et outils. Dans ce contexte, la cartographie fonctionnelle n’est plus un exercice de documentation, c’est un outil de travail.
L’essor de l’IA accentue encore ce besoin. Derrière les usages, ce sont toujours les mêmes fondations qui comptent : la qualité des données, la clarté des responsabilités, la maîtrise des flux et des interactions entre services. Sans une architecture fonctionnelle structurée, les systèmes deviennent rapidement illisibles, les redondances se multiplient et les initiatives perdent en efficacité. Le sujet n’est donc pas seulement technologique, il est avant tout structurel.
C’est dans ce contexte que le POS retrouve toute sa pertinence. Il ne s’agit pas de revenir à un urbanisme rigide ou à des schémas directeurs figés, mais de disposer d’un cadre fonctionnel capable d’accompagner l’évolution du système dans le temps. Le POS ne remplace ni l’agilité, ni les choix techniques, mais il permet de les inscrire dans une logique d’ensemble, compréhensible et maîtrisée.
Ce que l’on cherche, au fond, ce n’est pas à modéliser parfaitement le système d’information. C’est à garder une capacité de lecture, de décision et d’évolution dans un environnement qui devient de plus en plus complexe. Et sur ce point, le POS reste un outil structurant, peut-être plus qu’il ne l’a jamais été.
Dans un environnement où les systèmes d’information sont redevenus centraux, où les enjeux data et IA s’accélèrent, le POS n’est pas un outil du passé. C’est un cadre qui redevient essentiel pour maîtriser la complexité, structurer l’architecture et faire évoluer le système sans le subir.
C’est d’ailleurs exactement sur ces sujets que l’on intervient chez Eleven Labs, agence de conseil et d’ingénierie web & IA, que ce soit à travers des accompagnements en Architecture as a Service ou des missions de conseil en architecture du SI et en cartographie du système d’information. L’objectif reste toujours le même : redonner une lecture claire du système, poser un cadre structurant et permettre aux équipes de reprendre la maîtrise sur des environnements devenus trop complexes.
Vous avez du mal à garder une vision globale de votre SI ?
On vous accompagne pour structurer votre cartographie et votre architecture.
