Plan d'Occupation des Sols (POS) : comprendre le concept clé de l'urbanisation du SI
Si vous évoluez dans une DSI ou que vous vous intéressez à l’architecture d’entreprise, vous avez sans doute déjà croisé l’expression Plan d’Occupation des Sols, ou POS. Emprunté au vocabulaire de l’urbanisme, ce terme désigne aujourd’hui l’un des livrables les plus structurants de l’urbanisation du système d’information (SI). Pourtant, malgré son ancienneté dans la discipline, le POS reste souvent mal compris, confondu avec une simple cartographie applicative ou négligé au profit d’outils plus « visibles » comme la CMDB.
Dans cet article, nous revenons sur l’origine du concept, sa définition précise, sa méthode de construction, et la manière dont il s’articule avec les autres livrables de l’urbanisation du SI.
Qu'est-ce que le Plan d'Occupation des Sols (POS) en urbanisation du SI ?
Le Plan d’Occupation des Sols est une représentation macroscopique du système d’information qui découpe celui-ci en grandes zones, quartiers et blocs fonctionnels, par analogie avec le découpage d’un territoire urbain en zones résidentielles, industrielles ou commerciales.
Cette métaphore urbanistique n’est pas anodine : elle a été popularisée en France dans les années 2000, notamment par les travaux du Club Urba-EA (association française de référence en urbanisation des SI), qui a largement contribué à diffuser le vocabulaire de l’urbanisme dans le monde de la DSI, urbanisation, zones, quartiers, îlots, POS.
Concrètement, le POS répond à une question simple mais essentielle : « Où se trouve telle fonction dans mon SI, et avec quoi doit-elle cohabiter ? »
Contrairement à la cartographie applicative, qui liste et positionne les applications existantes, le POS a une vocation prescriptive : il définit les règles d’implantation, un peu comme un vrai plan d’occupation des sols urbain fixe ce qu’il est possible de construire (ou non) dans chaque zone d’une commune.
Le découpage en zones, quartiers et îlots
La construction d’un POS repose sur une décomposition hiérarchique du SI en trois niveaux de granularité :
1. Les zones
Les zones représentent les grands ensembles cohérents du SI, généralement définis selon deux axes structurants
- L’axe métier : Pilotage, Production, Support, Ressources
- L’axe technique : Front-office, Middle-office, Back-office, Référentiels partagés
Une zone typique pourrait être « Zone Relation Client » ou « Zone Référentiels d’entreprise ».
2. Les quartiers
À l’intérieur de chaque zone, les quartiers regroupent les fonctions qui partagent une forte cohérence métier et manipulent les mêmes objets. Par exemple, dans une zone « Relation Client », on peut trouver un quartier « Gestion des contrats » et un quartier « Support et réclamations ».
3. Les îlots (ou blocs fonctionnels)
Le niveau le plus fin découpe chaque quartier en blocs fonctionnels homogènes, ceux-là mêmes qui seront ensuite mis en correspondance avec les applications réelles du SI lors de la cartographie applicative.
Cette hiérarchie zones > quartiers > îlots constitue l’ossature du POS et permet de raisonner sur le SI indépendamment des solutions techniques en place, c’est précisément ce qui en fait un outil de gouvernance durable, contrairement à une cartographie applicative qui doit être mise à jour à chaque changement d’outil.
Pourquoi le POS est-il structurant pour une DSI ?
Il découple le métier de la technique
Le POS décrit le « quoi » (les fonctions nécessaires à l’entreprise) indépendamment du « comment » (les applications qui les réalisent aujourd’hui). Cette séparation est fondamentale : elle permet de faire évoluer les solutions techniques sans remettre en cause la structure fonctionnelle de référence.
Il sert de référentiel pour arbitrer les projets
Quand un nouveau besoin métier émerge, le POS permet de répondre rapidement à une question stratégique : dans quel quartier ce besoin doit-il être adressé, et par quelle application existante, évitant ainsi la prolifération d’applications redondantes qui répondent au même besoin fonctionnel.
Il facilite la détection des doublons et des zones de dette
En confrontant le POS (la cible fonctionnelle) à la cartographie applicative réelle (l’existant), les architectes identifient rapidement :
- les doublons applicatifs : plusieurs applications qui couvrent le même îlot fonctionnel
- les trous fonctionnels : des besoins métier non couverts
- les débordements : une application qui déborde largement de son quartier d’origine, signe fréquent de dette technique et de « bricolage » historique
Il structure les décisions de rationalisation et de migration
Lors d’un projet de refonte, de migration cloud ou de fusion-acquisition, le POS constitue la grille de lecture qui permet de replacer chaque application dans une logique fonctionnelle globale, plutôt que de raisonner projet par projet.
POS, cartographie applicative, CMDB : quelles différences ?
Ces trois notions sont souvent confondues alors qu’elles répondent à des besoins différents et complémentaires :
| Outil | Rôle | Niveau de représentation | Fréquence de mise à jour |
|---|---|---|---|
| POS (Plan d’Occupation des Sols du SI) | Décrit l’organisation fonctionnelle cible du système d’information en zones, quartiers et îlots. Il sert de référence pour structurer le SI. | Stratégique / Métier | Faible : uniquement lors d’évolutions majeures de l’organisation ou de la stratégie. |
| Cartographie applicative | Représente les applications du SI et leur rattachement aux différentes zones fonctionnelles définies par le POS. | Applicatif | Régulière : à chaque évolution du portefeuille applicatif ou des projets. |
| CMDB (Configuration Management Database) | Inventorie les composants techniques du SI (serveurs, bases de données, équipements, configurations, etc.) et leurs relations. | Technique / Infrastructure | Continue : souvent alimentée automatiquement ou mise à jour en temps réel. |
Le POS est donc la couche la plus stable et la plus stratégique des trois. Il change rarement, car il reflète la structure métier de l’organisation plutôt que ses choix technologiques du moment. C’est ce qui en fait un outil de gouvernance à long terme, à l’inverse d’une CMDB qui offre une vue statique et technique, sans porter la dimension stratégique de l’urbanisation.
Comment construire un Plan d'Occupation des Sols ? Méthode en 4 étapes
Étape 1 : Cadrer les axes de découpage
Avant toute chose, il faut choisir les axes structurants du découpage (métier, canal, ligne de service…). Ce choix doit être fait en cohérence avec l’organisation réelle de l’entreprise, sous peine d’obtenir un POS déconnecté du terrain.
Étape 2 : Identifier les grandes zones fonctionnelles
Un atelier avec les directions métier et la DSI permet de définir 5 à 10 grandes zones qui couvrent l’ensemble du périmètre de l’entreprise, sans zone de recouvrement.
Étape 3 : Décliner en quartiers et îlots
Chaque zone est ensuite affinée en quartiers, puis en îlots fonctionnels. Cette étape est généralement la plus consommatrice en ateliers, car elle nécessite un dialogue fin entre les équipes métier (qui connaissent les processus) et les architectes (qui structurent la représentation).
Étape 4 : Confronter à l’existant
Le POS cible est ensuite mis en regard de la cartographie applicative réelle pour visualiser les écarts, préparer les feuilles de route de rationalisation et prioriser les projets de transformation.
Cette dernière étape est celle où un outil de cartographie dynamique prend tout son sens : plutôt que de figer le POS dans une slide statique, une solution comme myCarto permet de superposer en temps réel le référentiel cible (POS) et la réalité applicative, et de faire vivre cette confrontation au fil des projets plutôt qu’une fois par an lors d’un audit.
Le POS dans les référentiels d'architecture d'entreprise (TOGAF, Praxeme...)
Le concept de POS, bien que très français dans sa terminologie (héritée du Club Urba-EA), trouve des équivalents dans les référentiels internationaux d’architecture d’entreprise :
- Dans TOGAF, la logique se rapproche de l’Architecture Continuum et des vues de la Business Architecture, qui structurent également le SI par capacités métier plutôt que par applications.
- La méthode Praxeme utilise la notion de système d’entreprise et une décomposition sémantique proche de l’esprit du POS.
- Le Business Capability Model, largement utilisé dans les approches anglo-saxonnes, poursuit un objectif similaire : décrire ce que l’entreprise sait faire, indépendamment de la manière dont elle le fait aujourd’hui.
Cette convergence conceptuelle explique pourquoi les outils de cartographie modernes, compatibles avec plusieurs méta-modèles (TOGAF, Praxeme, Archimate ou des approches sur-mesure), permettent de construire un POS quelle que soit la maturité méthodologique de départ de l’organisation.
Les erreurs fréquentes dans la construction d'un POS
- Confondre découpage fonctionnel et organigramme : le POS doit refléter les fonctions du SI, pas la structure hiérarchique de l’entreprise, qui elle évolue souvent plus vite.
- Vouloir un niveau de détail trop fin dès le départ : un POS trop granulaire dès sa première version devient vite ingérable et décourage son adoption par les équipes.
- Le figer une fois pour toutes : un POS doit rester un référentiel vivant, challengé à chaque évolution stratégique majeure (nouvelle offre, acquisition, transformation digitale).
- Le construire sans les équipes métier : un POS élaboré uniquement par la DSI, sans validation des directions métier, perd rapidement sa légitimité et son usage opérationnel.
Votre POS mérite mieux qu'une slide figée. Voyez comment le faire vivre avec myCarto.
FAQ : Plan d'Occupation des Sols et urbanisation du SI
Le POS est-il obligatoire pour urbaniser un SI ?
Non, mais il est fortement recommandé. C’est le livrable qui donne du sens aux autres travaux d’urbanisation (cartographie applicative, plans de transformation) en les rattachant à une vision fonctionnelle cible partagée.
Quelle est la différence entre un POS et une cartographie applicative ?
Le POS décrit la structure fonctionnelle cible du SI (zones, quartiers, îlots), indépendamment des solutions techniques. La cartographie applicative positionne les applications réelles dans cette structure. Le premier est stratégique et stable, la seconde est opérationnelle et évolutive.
Qui doit être impliqué dans la construction d'un POS ?
Idéalement, les architectes d’entreprise, la DSI et les directions métier, réunis lors d’ateliers dédiés. L’implication des métiers dès la conception est ce qui garantit l’adoption et la pertinence du référentiel dans la durée.
Combien de temps faut-il pour construire un POS ?
Cela dépend de la taille et de la maturité de l’organisation : de quelques semaines pour une PME à plusieurs mois d’ateliers itératifs pour un grand groupe multi-métiers. L’essentiel est de démarrer avec un premier niveau de granularité simple, puis d’affiner progressivement.
Quel outil utiliser pour construire et maintenir un POS ?
Un tableur ou une slide suffisent pour une première ébauche, mais ils atteignent vite leurs limites dès que le POS doit être confronté régulièrement à la réalité applicative. Une solution de cartographie dynamique comme myCarto permet de faire vivre le POS, de le relier automatiquement aux applications réelles, et de visualiser les écarts en continu plutôt que lors d’audits ponctuels.
En conclusion
Le Plan d’Occupation des Sols reste, encore aujourd’hui, l’un des livrables les plus sous-estimés de l’urbanisation du système d’information. Trop souvent relégué à un exercice ponctuel réalisé lors d’un audit ou d’un projet de refonte, il constitue pourtant le référentiel le plus stable et le plus stratégique dont dispose une DSI pour piloter durablement son SI, bien au-delà des effets de mode technologiques.
Construire un POS, c’est se donner les moyens de répondre à des questions essentielles avant qu’elles ne deviennent des urgences : où implanter un nouveau besoin métier, quelles applications rationaliser, quelles zones du SI concentrent la dette technique. Mais un POS figé dans une slide perd rapidement sa valeur. Pour qu’il reste un véritable outil de pilotage, il doit être confronté en continu à la réalité applicative, c’est précisément ce que permet une solution de cartographie dynamique comme myCarto.
