Donner à votre agent IA le contexte de votre SI

Votre agent IA de développement ne lit que le dépôt où il travaille. Il ignore que trois autres applications consomment le champ qu'il va renommer, que l'ERP appelle le service qu'il va supprimer, ou quelle équipe est responsable du système pour lequel il ouvre un ticket. Alors il devine, et une supposition assurée sur l'architecture suffit à transformer une modification banale en incident. Le contexte d'architecture est devenu une ressource à fournir délibérément à vos agents.

TL;DR

Claude Code, Cursor ou Codex voient le code qu'ils ont sous les yeux, pas le SI qui l'entoure : consommateurs, responsables, hébergement, processus métier.
Trois façons de leur donner ce contexte : fichiers dans le dépôt, pages de wiki, ou serveur MCP connecté à un référentiel d'architecture. Seul le dernier est partagé entre dépôts et reste interrogeable.
Un bon contexte répond à cinq questions : quel est ce système, avec qui échange-t-il, qui en répond, où tourne-t-il, quels processus en dépendent.
Exigez la lecture seule par défaut, un jeton par organisation et la journalisation de chaque appel.
UrbaHive expose son référentiel via un serveur MCP, sur tous les plans, gratuit compris.

Que ne sait pas votre agent IA de votre système d'information ?

Votre agent connaît le code qu'il peut ouvrir, et rien des systèmes avec lesquels ce code communique. Hors du dépôt, il n'a plus de source et comble le vide avec un texte plausible.

Renommer un champ. L'agent renomme le champ customerRef d'un service de commandes, tests et OpenAPI compris. Rien dans le dépôt n'indique que la facturation, l'entrepôt de données et un portail partenaire le lisent dans un export. Trois consommateurs cassent en production.
Décommissionner un service. L'agent supprime un service de tarification « legacy » sans appelant dans le monorepo. L'ERP l'appelait chaque nuit par un flux batch absent du code : la facturation échoue.
Adresser le travail à la mauvaise équipe. Un agent d'exploitation affecte un ticket d'incident à l'auteur du dernier commit. Le vrai responsable de l'application et le contact éditeur ne figurent nulle part où l'agent peut regarder.

Aucun de ces cas n'est une erreur du modèle. Ce qui manque, c'est la cartographie applicative (quelles applications, quels échanges, quels responsables), d'où l'intérêt d'une documentation d'architecture vivante fondée sur la donnée plutôt que sur le dessin. Un agent interroge des données ; il ne lit pas un schéma périmé.

Quelles sont les trois façons de donner du contexte d'architecture à un agent ?

Vous pouvez placer le contexte dans le dépôt, dans un wiki, ou derrière un serveur MCP connecté à un référentiel d'architecture. Elles se complètent sans couvrir le même périmètre.

Approche	Fraîcheur	Couverture entre dépôts et systèmes	Contrôle d'accès	Traçabilité	Effort
Fichiers dans le dépôt (README, ARCHITECTURE.md, AGENTS.md)	Bonne pour le code, faible pour ce qui l'entoure	Un dépôt ; contradictoire d'un dépôt à l'autre	Quiconque lit le dépôt	Historique Git du fichier	Faible
Pages de wiki collées dans le prompt	Manuelle ; souvent en retard de plusieurs mois	Large en théorie, éparpillée en pratique	Droits du wiki, puis copie dans le prompt	Aucune	Moyen, récurrent
Serveur MCP sur un référentiel d'architecture	Celle du référentiel partagé	Tout le SI : applications, flux, serveurs, processus, responsables	Jeton limité à une organisation, lecture seule par défaut	Chaque appel journalisé	Faible une fois le référentiel en place

La règle pratique : le contexte du code (modules, conventions, tests) reste dans le dépôt ; le contexte du SI vient d'un référentiel partagé. Un ARCHITECTURE.md qui liste tous les consommateurs de chaque API sera faux avant la fin du trimestre.

Le MCP (Model Context Protocol), standard ouvert d'appel d'outils sur un serveur externe, permet à l'agent d'interroger le référentiel au moment voulu plutôt que de lire une copie vieille de plusieurs semaines.

Que doit contenir un bon contexte d'architecture ?

Un bon contexte d'architecture répond aux cinq questions du tableau ci-dessous pour tout système que l'agent touche. Le plus fin (endpoints, noms de champs, schémas) relève du code et de ses contrats.

Question à laquelle l'agent doit répondre	Comment UrbaHive l'enregistre
Quel est ce système ?	Fiche application : description, statut (typologie propre à chaque organisation), éditeur, stack technique, service interne ou externe, document d'architecture technique (DAT) et sa version
Avec qui échange-t-il, et dans quel sens ?	Flux : application source → application cible, type, fréquence, indicateur bidirectionnel
Qui en répond ?	Un responsable par application, plus des contacts additionnels, internes ou externes
Où tourne-t-il ?	Serveurs et infrastructures reliés aux applications qu'ils hébergent
Quelle activité métier en dépend ?	Étapes de processus reliées aux applications ; capacités avec un responsable et une criticité

Deux détails comptent plus que le volume. Le sens des flux : « B consomme un export nocturne de A » dit qui casse si A change. Une personne nommée : un alias d'équipe ne dit pas à qui demander avant de merger. Si la responsabilité applicative est votre point faible, commencez par une matrice des responsables d'applications.

Côté granularité, le référentiel sait que la facturation reçoit un flux du service de commandes, pas que ce flux transporte customerRef : la cartographie dit quels consommateurs vérifier, le code dit ce que chacun lit.

Au-delà d'un produit et de quelques dépôts, un référentiel partagé devient rentable : le plan gratuit d'UrbaHive (1 utilisateur, 25 applications, sans carte bancaire) suffit pour connecter un assistant à une première cartographie.

Comment connecter un agent à vos données d'architecture en sécurité ?

Avec un jeton limité à une organisation, en lecture seule sauf décision contraire, et journalisé à chaque appel : c'est le minimum à exiger de tout serveur MCP. Le connecteur d'UrbaHive, en référence :

Un jeton par organisation. Un jeton d'accès personnel n'atteint qu'une organisation, même si l'utilisateur appartient à plusieurs.
Lecture par défaut, écriture sur décision. Le connecteur compte 74 outils : 32 en lecture, 42 en écriture. Un jeton est en lecture seule sauf si la portée « écriture » a été activée à sa création, et l'écriture exige en plus un rôle suffisant.
Aucun outil ne peut supprimer une application, un flux ou un autre objet de la cartographie. Le seul outil destructif supprime une définition de champ personnalisé ; il est réservé au propriétaire de l'organisation et demande une confirmation en deux temps.
Limitation et journalisation. 60 requêtes par minute par jeton ; chaque appel est inscrit au journal d'audit, aux côtés de chaque modification faite dans l'application.
Hébergement. Données hébergées dans l'UE, chiffrées en transit et au repos.

Une limite à exposer à votre RSSI : ce que l'agent lit est transmis au fournisseur de l'assistant et traité selon ses conditions, indépendamment du référentiel. Choisissez l'assistant autorisé et tenez les données personnelles hors des descriptions libres. L'article MCP, sécurité et RGPD traite les objections habituelles d'un RSSI.

Quelles questions votre agent peut-il poser à la cartographie ?

Toute question à laquelle les données de la cartographie répondent : inventaires, flux, hébergement, responsables, processus, capacités, recherche et synthèse du SI. Jamais ce qui n'a pas été saisi.

Prompt	Ce que l'agent lit
« Quelles applications échangent des données avec SAP ERP, et dans quel sens ? »	La fiche de l'ERP et les flux où il est source ou cible
« Avant de modifier l'export du service de commandes, quelles applications le consomment, et qui en est responsable ? »	Les flux sortants du service, puis le responsable et les contacts de chaque cible
« Quels processus métier passent par Salesforce, et qui en sont les responsables ? »	Les étapes reliées à Salesforce, puis les processus et leurs responsables
« Quelles applications sont hébergées sur le serveur DB-FIN-02 ? »	La fiche du serveur et les applications qu'il héberge
« Quelles capacités n'ont aucune application support ? »	Les capacités et les applications qui leur sont rattachées
« Résume mon SI en cinq points. »	La synthèse d'architecture, puis les principaux programmes

Demandez les sources : « liste les flux que tu as utilisés » rend la réponse vérifiable dans l'application. Inscrivez la vérification dans les instructions de l'agent : une ligne dans CLAUDE.md, AGENTS.md ou vos règles Cursor, du type « avant de renommer ou supprimer tout ce qui sort de ce service, interroge UrbaHive sur les flux et les responsables de cette application », en fait une étape de la modification.

Connaissez les limites : la réponse n'est jamais plus à jour que la cartographie, et un flux non documenté n'apparaîtra pas. Les lectures enchaînées ne reconstruisent que les dépendances saisies : c'est pourquoi une checklist de décommissionnement « dépendances d'abord » exige toujours une validation humaine. D'autres scénarios dans les cas d'usage MCP en entreprise.

Comment le mettre en place ?

En trois étapes et quelques minutes, si la cartographie contient déjà des données.

Dans UrbaHive, ouvrez Settings → Connectors et générez un jeton pour l'organisation cible, écriture désactivée pour un premier test.
Ajoutez le serveur MCP d'UrbaHive à votre client (Claude Desktop, claude.ai, Claude Code, Cursor, Windsurf, Codex ou Devin). Le tutoriel pour Claude et les configurations client par client donnent les extraits exacts.
Demandez « Résume mon SI en cinq points », vérifiez la réponse, puis ajoutez l'instruction ci-dessus aux règles de projet de l'agent.

Si la cartographie est vide, un jeton en écriture permet à un agent de l'initialiser depuis votre code ; vous relisez ensuite ce qu'il a créé.

Questions fréquentes

Est-il sûr de connecter un assistant IA à mes données d'architecture ?

Oui, si le connecteur est en lecture seule par défaut, limité à une organisation et journalisé, et si votre organisation a validé l'assistant, dont le fournisseur traite ce qu'il reçoit. Avec UrbaHive, chaque appel est journalisé et les données sont hébergées dans l'UE.

L'agent peut-il modifier ma cartographie ?

Seulement si vous l'autorisez, par la portée « écriture » du jeton et un rôle suffisant. Même alors, aucun outil ne peut supprimer une application, un flux ou un autre objet de la cartographie ; le seul outil destructif supprime une définition de champ personnalisé, est réservé au propriétaire et demande une confirmation en deux temps.

Quels assistants sont compatibles ?

Claude Desktop, claude.ai, Claude Code, Cursor, Windsurf, Codex et Devin, avec une configuration documentée pour chacun.

Est-ce disponible sur le plan gratuit ?

Oui. Tous les plans incluent le connecteur MCP ; seuls les quotas diffèrent. Le plan gratuit couvre 1 utilisateur et 25 applications, sans carte bancaire ni limite de durée.

Donnez la cartographie à vos agents, pas une supposition

Vos agents agissent sur le contexte dont ils disposent. Pour les PME et ETI (de 50 à 5 000 collaborateurs), un référentiel partagé des applications, flux, responsables et processus est le moyen le plus économique de rendre ce contexte exact. Connectez votre assistant IA sur le plan gratuit : 1 utilisateur, 25 applications, sans carte bancaire. Créez votre compte UrbaHive.