Ce que l'architecture d'entreprise peut apprendre de l'urbanisme

Il y a quelques mois, en se baladant dans un vieux quartier de Lyon, un de nos architectes a eu une réflexion qui nous a marqués : « Ce quartier, c'est exactement un SI legacy. Des couches empilées sur des siècles, des ruelles qui ne servent plus à rien, des bâtiments rénovés à moitié, et pourtant, ça fonctionne. Les gens y vivent, y travaillent, s'y déplacent. »

On a trouvé le parallèle assez juste. Et en creusant un peu, on s'est rendu compte que l'urbanisme et l'architecture d'entreprise partagent beaucoup plus qu'on ne le pense. Pas juste des métaphores. Des problèmes concrets, des tensions similaires, et surtout des leçons que les urbanistes ont apprises depuis longtemps et que notre discipline est encore en train de découvrir.

Personne ne reconstruit une ville de zéro

C'est probablement la leçon la plus fondamentale.

Les urbanistes savent depuis toujours qu'on ne rase pas une ville pour en reconstruire une nouvelle. Ça n'arrive quasiment jamais (et quand c'est arrivé, les résultats ont rarement été à la hauteur des promesses, Brasilia en est un exemple intéressant). On travaille avec l'existant. On rénove, on étend, on réaménage, on contourne parfois.

En architecture d'entreprise, on a pourtant longtemps été fascinés par le "grand redesign". Le schéma directeur parfait, la cible à cinq ans, l'architecture idéale dessinée sur une page blanche. Et puis la réalité rattrape : le budget n'est pas là, les équipes sont occupées à maintenir l'existant, les priorités métier changent tous les six mois.

Les urbanistes appellent ça la ville palimpseste : chaque époque laisse sa trace, et la nouvelle couche se construit sur les précédentes sans jamais les effacer complètement. Un SI d'entreprise, c'est exactement ça. Du COBOL des années 80 qui tourne encore, un ERP déployé dans les années 2000, des microservices de 2022, et une couche IA de 2025.

Ce n'est pas un bug. C'est la nature même du système. Et les meilleurs urbanistes ne s'en plaignent pas : ils apprennent à travailler avec.

Le plan, le territoire et le décalage permanent

Les urbanistes ont un outil central : le Plan Local d'Urbanisme (PLU). C'est la cartographie officielle de la ville, avec ses zones, ses règles, ses projections.

Et tous les urbanistes vous le diront : le plan n'est jamais parfaitement à jour. Il y a toujours un décalage entre la carte et le terrain. Un bâtiment construit qui n'est pas encore sur le plan. Un usage qui a changé sans que le zonage suive. Un quartier qui s'est développé différemment de ce qui était prévu.

Ça vous rappelle quelque chose ?

En EA, on a le même sujet. La cartographie applicative est rarement un reflet exact du SI réel. Il y a des applications qui ont été décommissionnées mais qui sont encore sur la carte. Des flux qui ont changé sans que personne ne mette à jour le schéma. Des projets qui ont fait évoluer l'architecture sans repasser par le comité.

Ce que les urbanistes ont compris, c'est que le décalage n'est pas un échec. C'est structurel. L'enjeu n'est pas d'avoir un plan parfait, c'est d'avoir un plan suffisamment à jour pour prendre de bonnes décisions. Et pour ça, il faut que le plan soit facile à mettre à jour, pas un monument qu'on retouche une fois par an.

Zoner, c'est bien. Connecter, c'est mieux.

Une ville est découpée en zones : résidentiel, commercial, industriel, mixte. C'est utile pour organiser, réguler, planifier. Mais les urbanistes les plus intéressants vous diront que ce qui fait vraiment fonctionner une ville, ce ne sont pas les zones elles-mêmes. Ce sont les connections entre les zones.

Une ligne de métro qui relie un quartier résidentiel à un pôle d'emploi change la dynamique des deux quartiers. Une piste cyclable qui traverse un parc crée un flux de vie qui n'existait pas avant. Un marché à l'intersection de trois quartiers devient un lieu de brassage qu'aucun plan de zonage n'avait prévu.

En architecture d'entreprise, on a souvent la même tentation du zonage : on découpe le SI en domaines (Commerce, Finance, RH, IT), on attribue des responsabilités, on trace des périmètres. C'est nécessaire. Mais si on s'arrête là, on a une belle carte avec des zones bien colorées et aucune compréhension des flux qui les traversent.

La vraie valeur d'une cartographie d'architecture, comme celle d'un plan d'urbanisme, c'est de rendre visibles les connections : comment les données circulent entre les domaines, quels sont les points de passage critiques, où sont les goulets d'étranglement, quels chemins prennent les processus métier pour traverser les frontières organisationnelles.

La participation citoyenne et la collaboration en EA

Il y a un autre parallèle qui nous parle beaucoup.

Dans les années 60-70, l'urbanisme était une affaire d'experts. Des architectes et des technocrates dessinaient la ville d'en haut, et les habitants découvraient le résultat. Ça a donné des grands ensembles, des autoroutes urbaines, et pas mal de frustrations.

Depuis, l'urbanisme a évolué vers des modèles beaucoup plus participatifs. Consultations publiques, ateliers de co-design, budgets participatifs. L'idée étant que les gens qui vivent dans la ville ont une connaissance du terrain qu'aucun expert ne peut remplacer.

L'architecture d'entreprise est un peu au même carrefour. Pendant longtemps, la cartographie du SI était l'affaire d'un petit groupe d'architectes certifiés. Ils produisaient des modèles exhaustifs, dans un langage technique (ArchiMate, TOGAF), que le reste de l'organisation consultait rarement.

On voit de plus en plus d'équipes EA qui essaient d'ouvrir la démarche. Impliquer les responsables métier dans la cartographie. Rendre les vues lisibles pour les non-techniciens. Permettre aux équipes terrain de contribuer, de corriger, de compléter.

Ce n'est pas facile. Comme en urbanisme, la participation demande des outils adaptés, un langage commun, et une vraie volonté de partager le pouvoir de décision. Mais c'est probablement la direction dans laquelle les choses vont.

Penser en flux, pas en monuments

Les villes qui fonctionnent le mieux ne sont pas celles qui ont les plus beaux bâtiments. Ce sont celles où les gens circulent bien. Où l'énergie passe, où les interactions se font naturellement, où les services sont accessibles là où on en a besoin.

Jane Jacobs, une des penseuses les plus influentes de l'urbanisme moderne, défendait l'idée que la vitalité d'un quartier vient de sa diversité d'usages et de la densité de ses interactions, pas de la grandeur de ses plans. Elle se méfiait profondément des grands projets pensés d'en haut, et préférait observer comment les gens utilisaient réellement la ville avant de proposer quoi que ce soit.

Il y a quelque chose de très applicable à l'EA là-dedans. Les meilleurs systèmes d'information ne sont pas forcément les plus propres sur le papier. Ce sont ceux où les données circulent bien, où les équipes peuvent accéder à ce dont elles ont besoin sans passer par cinq intermédiaires, où les nouveaux services peuvent se brancher sans tout casser.

Penser l'architecture comme un réseau de flux plutôt que comme un ensemble de blocs, c'est un changement de perspective que les urbanistes ont fait il y a des décennies. On est probablement en train de le faire aussi.

C'est ce qu'on explore chez Boldo

Ce parallèle avec l'urbanisme nous inspire beaucoup dans la façon dont on conçoit Boldo.

On essaie de construire un outil qui s'inscrit dans cette logique : pas un monument qu'on met à jour une fois par an, mais un espace vivant qui reflète la réalité du terrain en continu.

Travailler avec l'existant. Boldo se connecte à vos sources de données réelles pour que la cartographie parte du SI tel qu'il est, pas tel qu'on aimerait qu'il soit.

Rendre les flux visibles. Au-delà des composants, comprendre comment les données circulent, quelles sont les dépendances, où sont les points critiques.

Ouvrir la participation. Un espace lisible et accessible où métiers et IT peuvent contribuer ensemble, sans avoir besoin d'un diplôme en modélisation.

Accepter le décalage. Plutôt que de viser la cartographie parfaite, rendre la mise à jour tellement simple que le décalage reste minimal.

La ville parfaite n'existe pas. Le SI parfait non plus. Mais on peut construire des outils qui aident à naviguer dans la complexité plutôt que de prétendre l'éliminer.