L’architecte applicatif, futur chef d’orchestre du développement agentique
Lors de la Duck Conf 2026, Matthieu Lagacherie, Senior Manager Data & AI chez Octo Technology, a détaillé les méthodes émergentes pour rendre le code et la documentation actionnables par les agents IA. Selon lui, l’architecte applicatif devra être le chef d’orchestre du contexte et des pratiques du développement agentique.
L’industrie du logiciel expérimente un changement en profondeur. Expérimenter est le bon terme, car les standards ne sont pas véritablement fixés. Les règles qui ont vu le jour ces derniers mois pourraient encore largement évoluer. Ce bouleversement est bien évidemment lié à l’IA agentique.
Malgré des mouvements imposés par les fournisseurs de LLM et les éditeurs d’outils, Matthieu Lagacherie, Senior Manager Data & AI chez Octo Technology, estime que c’est le bon moment pour adapter ses pratiques à cette nouvelle manière de bâtir des systèmes et des logiciels. « Il faut se concentrer davantage sur les méthodes et se laisser la liberté de changer d’outils agentiques tous les six mois, au besoin », juge-t-il.
Les effets de l’IA sur le métier d’architecte applicatif
La perception de cet enjeu est différente suivant les métiers IT. « Je m’intéresse particulièrement à son impact sur mon métier d’architecte applicatif », déclare Matthieu Lagacherie. Le consultant de la filiale d’Accenture présentait ses observations lors de la Duck Conf 2026 organisée le 24 mars 2026 par Octo.
Ce métier ne perdrait pas de son intérêt. Ses collègues et lui seraient de plus en plus sollicités. Mais au lieu de prendre une décision d’architecture toutes les semaines, l’IA générative conduit ces responsables vers « la prise de plusieurs décisions par jour ».
« Le premier apprentissage, c’est que nous avons beaucoup de leviers déjà présents et qui permettent de faciliter la mise en place de processus de développement agentique », avance-t-il.
Ces leviers sont relatifs à la documentation au sens large : schémas d’architecture, présentations de type PowerPoint, documentation du code, des pratiques et des librairies utilisées, « user stories », historique de modification de la base de code, etc.
Centraliser le code, la documentation et les savoirs
« Quand l’on commence à s’intéresser à l’écosystème IA, la documentation est en réalité le contexte des LLM », souligne Matthieu Lagacherie. « Alors que le rôle des architectes était déjà de partager ce savoir avec une équipe, il doit maintenant consolider et gérer cette connaissance pour finalement construire une sorte de vérité unique pour que les humains et les agents IA collaborent et prennent des décisions pertinentes ».
« Quand l’on commence à s’intéresser à l’écosystème IA, la documentation est en réalité le contexte des LLM ».
Matthieu LagacherieSenior Manager, Data & IA, Octo Technology
Pour que cela fonctionne avec des LLM et des agents IA, il faut rapprocher la documentation du code. L’architecture elle-même devrait être « as code ».
« L’architecture as code, c’est tout simplement le fait de spécifier nos architectures et de les colocaliser avec notre code dans des formats JSON, YAML, etc. », décrit-il.
La méthode associée au modèle d’architecture C4 et les outils comme Structurizr ou Mermaid, entre autres, peuvent aider à produire cette documentation.
La colocalisation du code et des diagrammes d’architectures applicatives « permet de réduire la dérive entre ce que vous portez comme message à vos équipes et ce qui a été réellement implanté ».
La rédaction de la documentation n’est pas forcément la tâche préférée des développeurs et des ingénieurs (et c’est un euphémisme). Elle est surtout dispersée dans des wikis internes. Parfois, des portions de documentations résident déjà dans les dépôts Git. Pour autant, cela ne suffirait pas pour obtenir les meilleurs résultats.
« Nous n’avons plus le loisir d’une gestion éclatée de la documentation », insiste l’architecte.
Néanmoins, l’IA générative c’est aussi moyen pour mettre à jour cette documentation de manière plus systématique.
« Outre la colocalisation du code et de la documentation, il convient de mettre en place des pratiques de génération et de regénération automatique de la documentation pour être certain qu’elle soit au plus proche de notre code », estime-t-il.
Il s’agit de s’assurer un meilleur suivi des spécifications et de rétrodocumenter les éléments de code qui ne l’aurait pas été ou pas suffisamment.
Qu’est-ce que la programmation Spec-Driven ?
Quand Matthieu Lagacherie parle de spécifications, il se réfère à l’approche dite Spec-Driven Development (SDD ou développement orienté par les spécifications dans la langue de Molière). Cette méthodologie d’ingénierie logicielle consiste à s’appuyer sur des spécifications lisibles par la machine et d’en faire la source de vérité principale pour dériver les implémentations, les tests et la documentation. Si ces origines peuvent être retracées jusqu’aux pratiques de la NASA dans les années 1960, elle a été formalisée en 2004 par des chercheurs de l’Université de York au Canada et au Royaume-Uni. Mais c’est bien l’avènement des frameworks agentiques qui l’a remise au goût du jour.
À gros trait, elle est utilisée pour encadrer les résultats du Vibe Coding. Dans le détail, ces spécifications sont des contrats d’interface (REST, gRPC, GraphQL, etc.), des règles métiers lisibles, des schémas de données ou encore des propriétés vérifiées. Elles sont généralement enregistrées au format Markdown dans la documentation.
Le Spec-Driven Development fait en tout cas consensus chez Anthropic, GitHub (Spec-Kit), AWS (Kiro) ou encore Tessl, une startup fondée par Guy Podjarny, cofondateur et ex-CEO de Snyk.
Matthieu Lagacherie évoque également un double rôle des agents IA : implémenter des spécifications ou interpréter du code existant pour les rédiger.
Il s’opère une bascule où la documentation est tout aussi importante que le code, voire davantage. « Le code devient un sous-produit des spécifications. Cela peut faire un peu peur, mais cela participe d’une nouvelle montée en abstraction », affirme le responsable. « Nous sommes passés de cartes perforées à des assembleurs, puis des assembleurs à des langages de plus haut niveau, des langages orientés objet, bref des approches de plus en plus fonctionnelles de la programmation ».
D’où l’importance d’un nouveau type de processus, selon Matthieu Lagacherie, à savoir la vérification d’architecture en continu. Le maintien du synchronisme entre la documentation, du code et de la structure applicative décrit plus haut est alors la clé pour éviter les gros problèmes.
« Le code devient un sous-produit des spécifications. Cela peut faire un peu peur, mais cela participe d’une nouvelle montée en abstraction ».
Matthieu LagacherieSenior Manager Data & IA, Octo Technology
Les agents IA peuvent en principe vérifier que le code généré est conforme aux principes d’architecture. « Inversement, l’on peut rédiger des prompts permettant à nos agents IA de suivre des contraintes d’architecture spécifiés dans la documentation », précise-t-il.
L’architecte est alors un chef d’orchestre. Il aide les équipes de développeurs à décrire les architectures, la documentation, à stocker les spécifications.
Les développeurs vont s’appuyer sur des agents IA pour réaliser l’implémentation et enrichir cette documentation.
Pour que cet écosystème collaboratif fonctionne à l’échelle de l’entreprise, une réorganisation structurelle s’impose. Idéalement, il convient de réorganiser les dépôts de code dans une logique « monorepo ». Au lieu de laisser les dépôts de code proliférer de manière isolée (« polyrepo »), ils sont rassemblés au sein de projets, eux-mêmes stockés dans un dépôt central unique, le monorepo. Les liens de dépendances entre les projets sont clairement définis.
« Si l’on se contente d’implémenter l’IA agentique au sein d’un seul projet, les gains ne sont pas si évidents », estime Matthieu Lagacherie. « Au-delà du bon contexte au niveau d’un projet ou d’une équipe, c’est à l’architecte de créer et maintenir un écosystème de partage ».
De même, alors que les « solo dev » à l’aise avec les agents IA s’expriment sur leur capacité à concevoir des applications seuls dans leur coin, en entreprise, c’est le collectif qui doit primer, juge-t-il. Il précise toutefois qu’il n’est pas toujours évident de mettre en place une approche monorepo.
« Agents.md », « Skills », MCP : les standards naissants du développement agentique
Au sein de cette structure centralisée, une nouvelle convention émerge pour guider les agents IA. Dans une approche agentique – et avant même de contenir du code – les projets incluent tous un fichier « agents.md ».
Ce format, né du travail d’OpenAI, de Google ou encore du Cursor, contient en quelque sorte « le boot file de l’IDE agentique », traduit Matthieu Lagacherie. « C’est là que nous pouvons spécifier des choses très contextualisées au projet : des pratiques de code, de tests, les boucles de feed-back, etc. », ajoute-t-il. Pour faire, simple, c’est là que résident les conventions de développement.
Le projet contient également le diagramme d’architecture C4 (au format JSON), le contexte et les règles métier (souvent maintenu manuellement), les décisions d’architecture ainsi que l’historique des modifications de code au format ADR (Architecture Decision Record).
« Puisque nous allons produire beaucoup plus de code qu’auparavant, l’historique des modifications du code et de l’architecture devient crucial », souligne l’architecte.
À cela s’ajoute une spécificité originellement développée par Anthropic, mais adoptée par la majorité des acteurs de l’IA générative : les « skills ».
« Ce sont des recettes agentiques pour effectuer certaines opérations dans nos dépôts, par exemple l’implémentation des tests de performance », illustre le responsable. Ils peuvent être partagés à l’échelle du monorepo.
Techniquement, ils mêlent des fichiers Markdown contenant des instructions et des scripts pour « administrer la base de code, lister les fichiers, effectuer du refactoring simple, etc., et des éléments de référence, par exemple pour effectuer des audits ».
Le responsable recommande d’embarquer au sein des skills des concepts que l’on souhaite implémenter : les grands principes d’une architecture performante, hexagonale, etc. « Les agents IA doivent les interpréter pour vous proposer un plan d’amélioration du code ».
« Les serveurs MCP permettent une capitalisation encore plus puissante », considère Matthieu Lagacherie. « Ils peuvent être déployés au niveau d’un service, par exemple pour consommer et modifier des tickets JIRA ».
À noter qu’un serveur MCP (Model Context Protocol) demande de manipuler du code, et non plus des instructions ou des fichiers de configuration.
Même s’ils sont agnostiques, les concepts derrière agents.md, les skills et les serveurs MCP sont globalement similaires. Pour Matthieu Lagacherie, l’architecte doit donc décider, en fonction des instructions et du contexte du niveau de partage de ces fonctions plus ou moins communes aux équipes de développeurs. Tout comme le niveau d’automatisation attendu définira les outils d’interaction avec les agents IA (IDE, IDE agentique, interface conversationnelle, etc.) et leurs droits d’accès à la CI/CD.
Dans un même temps, les agents IA sont limités par la fenêtre de contexte des grands modèles de langage. Il faut donc penser à une logique de divulgation progressive des skills, de compartimentation par type de tâches et évaluer la pertinence des sous-agents IA et la production de synthèse de la documentation.
De nouvelles habitudes à prendre
Outre le fait que le collectif est de plus en plus important, il faut également se départir de certains réflexes, estime l’architecte. Par exemple, la dette technique et le refactoring d’applications existantes sont désormais beaucoup plus accessibles. Plus question de les laisser de côté.
En revanche, s’il faut tendre vers une mise en commun des méthodes et des pratiques, la génération de code, elle, doit devenir une responsabilité individuelle. Le développeur doit maîtriser le volume et la lisibilité du code. Les pull requests, plus nombreux qu’à l’accoutumée, doivent pouvoir être relus par des humains.
De même, cela impose davantage de rigueur en matière de sécurité. Comme les fabricants automobiles qui conçoivent des véhicules toujours plus sophistiqués, plus de code à manipuler, c’est plus de problèmes à gérer. Il faut donc former les développeurs et déployer systématiquement des outils de vérification de code.
