Urbaniser son SI à l'ère de l'IA : poser l'IA sans casser l'existant

L'urbanisation du SI, en une image

Urbaniser un système d'information, c'est l'organiser comme on organise une ville : des quartiers aux fonctions claires, des voies de communication entre eux, et des règles d'urbanisme pour que l'ensemble évolue sans devenir un labyrinthe.

Sans plan d'urbanisme, un SI grossit par empilement : un logiciel ici, un outil cloud là, un tableur qui fait le lien. Ça marche un temps, puis chaque ajout coûte de plus en plus cher et chaque panne devient un casse-tête. L'IA, mal posée, accélère ce désordre.

Pourquoi l'IA rebat les cartes

Une application classique a un périmètre défini. L'IA, elle, est transversale par nature : pour être utile, elle veut accéder à vos documents, vos données métier, vos outils. Elle traverse tous les quartiers de la ville.

C'est précisément ce qui en fait un sujet d'urbanisme, et pas seulement d'outil. La question n'est pas « quelle IA acheter », mais « où la brancher, sur quelles données, via quelles portes, et avec quelles règles ».

Le piège : l'IA en silos

Le scénario le plus courant n'est pas l'absence d'IA — c'est l'IA partout, en désordre. Chaque service adopte son propre outil cloud, chacun colle ses données dans une interface différente, personne ne sait qui utilise quoi sur quelles informations. C'est ce qu'on appelle le « shadow AI ».

Le coût est double : de la dette technique (des intégrations qui se chevauchent, impossibles à maintenir) et un risque réel sur la donnée (du confidentiel qui part chez des tiers, sans contrat ni traçabilité — voir notre article sur le cadre légal). Urbaniser, c'est reprendre la main avant que le désordre ne s'installe.

Les bons principes d'urbanisme IA

Des interfaces standards plutôt que des branchements bricolés : on relie l'IA au SI par des portes claires — des API, ou le protocole MCP qui agit comme une « prise universelle » entre l'IA et vos outils. On évite de câbler l'IA en dur dans chaque logiciel.

Un couplage faible : chaque brique doit pouvoir être remplacée sans tout casser. Le modèle d'IA d'aujourd'hui ne sera pas celui de demain ; votre architecture doit le supposer dès le départ.

La donnée maîtrisée et la gouvernance des usages : on décide quelles données l'IA peut voir, on garde l'humain dans la boucle sur les décisions qui comptent, et on sait documenter qui fait quoi. C'est la base d'une IA défendable face au RGPD comme à l'AI Act.

La souveraineté est un choix d'urbanisme, pas un détail

Une question d'urbanisme prime sur toutes les autres : où la donnée est-elle traitée ? Envoyée dans le cloud d'un tiers, ou traitée localement, sur une infrastructure que vous maîtrisez ? Ce n'est pas un réglage technique, c'est une décision d'architecture qui engage durablement.

C'est la logique d'AQUIFÈRE : un quartier souverain qui se greffe proprement sur votre SI existant — via API ou MCP — pour interroger vos documents sans qu'ils en sortent jamais. L'IA devient une fonction du système, pas une fuite par la fenêtre.

Par où commencer, concrètement

On ne réurbanise pas une ville en une nuit, et on ne refond pas un SI d'un coup. On cartographie d'abord l'existant — quels outils, quelles données, quels flux. On identifie ensuite un ou deux cas d'usage à fort impact, et on pose les bonnes interfaces autour, plutôt que de tout brancher partout.

Une gouvernance légère mais réelle, puis on itère. C'est exactement le terrain d'un ingénieur embarqué (voir notre article sur le Forward Deployed Engineer) : quelqu'un qui pose l'IA dans le système réel, au rythme des usages, sans big bang.

En résumé

L'IA ne se pose pas à côté du SI : elle s'y intègre, ou elle le déstructure. Urbaniser, c'est faire le premier choix plutôt que de subir le second — des interfaces claires, un couplage faible, la donnée maîtrisée, et la souveraineté traitée comme une décision d'architecture. C'est la différence entre une IA qui dure et une IA qu'on devra démonter dans six mois.