Cinq usages des agents de code pour éclairer une architecture logicielle

Un agent de code peut écrire une fonction, modifier plusieurs fichiers et lancer des commandes. Son intérêt pour l’architecture logicielle commence pourtant avant l’implémentation : il peut aider à réduire les zones inconnues d’un système, à condition de lui confier une enquête bornée plutôt qu’une refonte globale.

Le cas de départ est courant : une architecture moderne s’appuie encore sur un service ancien pour une tâche précise, alors que sa documentation est incomplète ou plus vraiment fiable. Le risque ne vient pas seulement de l’âge du composant. Il vient de ce que l’équipe croit savoir de ses contrats, de ses dépendances et de ses effets de bord.

Voici cinq usages concrets d’un agent de code pour travailler sur cette connaissance. Ils constituent des protocoles proposés, pas des résultats d’essai exécutés. Dans chaque cas, l’agent analyse ou prépare des éléments ; la décision d’architecture reste humaine.

Le scénario : un service legacy dont le contrat est flou

Imaginons une équipe qui doit faire évoluer une application composée de plusieurs services. L’un d’eux reçoit encore des requêtes importantes, mais son rôle exact est dispersé entre le code, les scripts de déploiement, les tests et quelques notes anciennes. Une demande vague comme « moderniser ce service » donnerait à l’agent un périmètre impossible à vérifier.

Le premier geste consiste donc à lui demander de produire des observations séparées des hypothèses. Chaque constat doit pointer vers un fichier, une fonction, un test ou une configuration effectivement disponible dans le dépôt. Si une information manque, l’agent doit l’indiquer au lieu de compléter le tableau par une supposition.

1. Cartographier les frontières avant de parler de refonte

Un agent peut parcourir un dépôt pour dresser une carte de dépendances : points d’entrée, appels sortants, formats échangés, fichiers de configuration, jobs planifiés et tests associés. La sortie utile n’est pas un grand diagramme décoratif. C’est une liste de frontières vérifiables, accompagnée des éléments qui les justifient.

La consigne doit limiter le travail à une zone précise : un service, un module ou un flux métier. L’agent peut classer chaque relation en trois catégories : observée dans le code, suggérée par un test, ou non confirmée. Cette distinction évite de transformer une recherche rapide en vérité d’architecture.

• Définir le répertoire et les fichiers autorisés à l’analyse.
• Demander les références exactes utilisées pour chaque relation.
• Séparer les dépendances d’exécution des dépendances supposées.
• Marquer les appels dont le contrat n’est pas documenté.

2. Reconstituer le contrat d’un service mal documenté

Lorsque la documentation ne suffit pas, l’agent peut comparer plusieurs indices : signatures, validations d’entrée, structures de sortie, gestion des erreurs et cas de test. L’objectif n’est pas de rédiger une documentation élégante à partir de quelques noms de fonctions. Il s’agit de produire une fiche de contrat provisoire, avec ses zones d’incertitude.

Cette fiche peut répondre à quatre questions : que reçoit le service, que renvoie-t-il, dans quels cas échoue-t-il et quels effets secondaires sont visibles dans le dépôt ? Les réponses doivent rester attachées aux preuves disponibles. Une hypothèse utile est une hypothèse explicitement étiquetée, qui pourra être confirmée par une personne connaissant le système.

Pour cadrer ce travail, les équipes peuvent reprendre une méthode de context engineering pour agents de code : placer les règles stables dans les instructions, garder le contexte propre à la tâche séparé et ne pas confondre information consultée et action autorisée.

3. Faire émerger les décisions cachées dans le code

Une architecture ne se résume pas à ses composants. Elle contient aussi des choix parfois invisibles : tolérance à l’échec, ordre des appels, conservation d’un format historique ou dépendance à une valeur par défaut. Un agent peut relire un chemin d’exécution et formuler les décisions qu’il semble incorporer.

Le bon livrable est une liste de décisions à confirmer, pas une explication définitive. Par exemple : « le module attend-il toujours cette valeur ? », « cette erreur doit-elle interrompre le flux ? » ou « ce format est-il consommé ailleurs ? ». Chaque question doit être reliée à une observation et à une vérification possible.

Cette étape est particulièrement utile avant de choisir entre conserver, encapsuler ou remplacer un service. Elle déplace la discussion de « quel framework adopter ? » vers « quel comportement devons-nous préserver ? ».

4. Tester une hypothèse d’architecture sans prétendre avoir validé le système

Un agent peut préparer des tests ciblés ou une fixture destinée à vérifier une hypothèse. L’équipe peut lui demander de couvrir un seul flux : une entrée représentative, une erreur connue ou une interaction entre deux composants. Tant que ces tests n’ont pas été exécutés dans un environnement décrit, ils restent un protocole proposé.

La différence est essentielle. Générer un test ne prouve ni la compatibilité du service ni la solidité de l’architecture. Le test sert à rendre la question exécutable et à montrer ce qui devra être observé. Si son résultat contredit l’hypothèse, l’équipe dispose d’un signal ; si le test passe, elle ne dispose que d’une preuve limitée à son périmètre.

5. Transformer l’enquête en décision d’architecture relisible

Le dernier usage consiste à demander à l’agent de condenser les observations dans un document de décision. Il ne doit pas choisir à la place de l’équipe. Il peut présenter le problème, les options envisagées, les contraintes connues, les preuves disponibles et les questions encore ouvertes.

Une bonne décision distingue clairement trois niveaux : ce que le dépôt montre, ce que l’équipe déduit et ce qu’elle décide. Cette séparation évite qu’une formulation produite par l’agent soit reprise plus tard comme un fait établi. Elle facilite aussi la transmission aux développeurs qui n’ont pas participé à l’enquête initiale.

Si la décision conduit finalement à une transformation de code, elle peut être traitée avec une méthode de migration du code legacy par petites étapes, en conservant une tranche de changement suffisamment petite pour être relue et réversible.

Checklist avant d’accepter la synthèse de l’agent

• Le périmètre du dépôt et des fichiers analysés est-il explicite ?
• Chaque affirmation importante renvoie-t-elle à une preuve identifiable ?
• Les faits, les hypothèses et les décisions sont-ils séparés ?
• Les contrats incertains sont-ils marqués comme tels ?
• Les tests proposés ont-ils un objectif et un résultat attendu précis ?
• Aucune modification durable n’a-t-elle été lancée sans validation ?
• Un responsable humain a-t-il relu la synthèse et les limites ?

Le bon rôle pour l’agent

Un agent de code peut réduire le temps nécessaire pour retrouver des relations, comparer des fichiers et préparer des questions. Il ne transforme pas une documentation incomplète en connaissance certaine et ne remplace pas les personnes qui connaissent les contraintes opérationnelles du système.

Pour améliorer une architecture, son rôle le plus fiable est donc celui d’un enquêteur encadré : observer, relier, signaler les contradictions et préparer des vérifications. La décision finale doit rester attachée à des preuves proportionnées au risque du changement, pas à la fluidité de la synthèse produite.