Duck Conf 2026 – CR – L’Architecte à l’ère de l’Agentic AI
Un nouveau paradigme : le goulot d’étranglement se déplace
À l'ère de l'Agentic AI, le facteur limitant d'un projet logiciel n'est plus notre capacité à développer, il se déplace en amont. Ce n'est plus « comment construire ? » mais « que doit-on construire ? » qui devient la question centrale. C'est le constat d'ouverture de Matthieu Lagacherie, architecte AI chez OCTO Technology, lors de son talk à la Duck Conf 2026.
L’IA générative ne supprime pas les goulots d’étranglement : elle les déplace vers la spécification, les boucles de feedback et l’adoption. Dans le cycle de développement classique, le facteur limitant se situe sur la phase de développement. Dans le cycle Agentic, cette phase est compressée, mais la pression se reporte sur la spécification, le feedback et l’adoption, un entonnoir inversé.
Conséquence directe pour l’architecte : là où il prenait une décision d’architecture par semaine, il en prend désormais plusieurs par jour. L’Agentic accélère le cycle de développement, mais aussi celui du design applicatif. Moins d’implémentation, mais plus d’arbitrages. La question posée par Matthieu est alors : comment adapter nos pratiques et nos standards à cette nouvelle réalité ? Il nous livre cinq apprentissages.
Apprentissage 1 — Les leviers qui transforment notre métier
Loin de disparaître, le rôle de l’architecte devient central dans l’ère Agentic. Matthieu identifie un dénominateur commun à tous les leviers de valeur de l’architecte : la documentation. Documentation d’architecture, connaissance du SI, spécifications, user stories, documentation projet… Tout cela constitue du contexte pour l’IA. L’architecte devient ainsi le « Context Engineer du SI » : sa valeur réside dans sa capacité à transformer la connaissance en contexte fiable et actionnable, consommable aussi bien par les humains que par les agents IA.
Comment faire concrètement ? Matthieu détaille quatre leviers, chacun présenté selon un triptyque « C’est quoi ? / Pourquoi c’est important ? / Quel levier avec l’Agentic AI ? ».
Architecture as Code (AaC)
L’architecture est décrite en code (modèle, règles, décisions), versionnée dans Git et automatisable (documentation, diagrammes, contrôles). L’exemple donné est l’architecture C4. L’intérêt est double : cela réduit la dérive entre l’architecture et le code, et rend l’architecture vérifiable en continu. Côté Agentic, l’AaC fournit directement du contexte structuré sur l’application et le SI, opérable par les agents.
Living Documentation
Les docs sont traités en « docs-as-code » : versionnés avec le code et régénérés automatiquement. L’objectif est d’éviter la « doc drift », ce décalage inévitable entre la documentation et le système réel. Pour les agents, cela produit du contexte texte fiable directement consommable, avec traçabilité et mise à jour intégrées.
Specification-as-code
Les specs et user stories sont colocalisées et synchronisées avec la base de code. Cela ouvre la voie au spec-driven development et aux pratiques de rétro-documentation. Un cycle vertueux s’installe entre spécifications, développement, tests et capitalisation des best practices. Avec l’Agentic AI, on entre dans un cycle d’amélioration continue entre les spécifications (texte) et le code.
Des produits dans un SI « Agentic »
Matthieu propose de passer de moins d’applications « verticales » à plus de design sous forme de capacités IA, typiquement standardisées via MCP (Model Context Protocol). L’avantage : moins de « sur-mesure », plus de réutilisation et de gouvernance. Les agents peuvent découvrir et appeler ces « tools » directement via une Gateway IA. L’application devient consommable aussi bien par les agents que par les humains.
Apprentissage 2 — Doc/Structure is the new code
Le code devient un sous-produit de la spécification. Matthieu invite à favoriser la structure et l’architecture plutôt que le code brut. Il replace cette idée dans l’histoire de l’informatique : cartes perforées → assembleur → langages de haut niveau → agentic coding. Chaque saut d’abstraction a suscité la même peur, celle de ne plus maîtriser les détails, et chaque fois, la réponse a été de construire un écosystème qui synchronise les niveaux.
L’architecte est comparé à un chef d’orchestre qui compose une partition (Architecture, ADR, Docs, Specs, Pratiques) que l’équipe interprète. Le nouveau paradigme repose sur une synchronisation bidirectionnelle entre Doc/Structure et Implémentation.
Concrètement, Matthieu présente une arborescence de référence pour un repository de produit. Trois types de fichiers y cohabitent : l’Agent Bootfile (AGENTS.md) contenant les coding standards, guardrails et conventions, chargé systématiquement par l’agent ; le Specific Knowledge (fichiers dans docs/) capturant le contexte métier et les repères d’architecture, chargé à la demande ; et les Agent Skills (dans skills/), des playbooks exécutables mêlant Markdown et scripts.
my-product-repository/
├── README.md
├── AGENTS.md # Bootfile: agent guardrails + operating mode
├── docs/ # Context
│ ├── architecture/
│ │ ├── overview.md # High-level context
│ │ ├── c4/archi.c4 # Architecture as code
│ │ └── decisions/ # Keep ADRs to help agent on specific updates
│ │ │ ├── ADR-0001-tech-stack.md
│ │ │ └── ADR-0002-auth.md
│ ├── domain/
│ │ ├── python_hexa.md # Hexagonal architecture best practices
│ │ ├── billing_rules.md
│ │ └── data_classification.md
│ └── runbooks/
│ ├── incident_response.md # Specific context for incident
│ └── release_process.md
├── skills/ # "Agent skills" = reusable capability playbooks
│ ├── refactoring-skills/
│ │ ├── SKILL.md
│ │ └── check_refacto.py
│ └── retrodoc-skills/
│ └── SKILL.md
└── CHANGELOG.md
Arborescence de référence d’un repository « Agentic-ready » : AGENTS.md, docs/, skills/
Apprentissage 3 — Le bon contexte et le bon écosystème de partage
Matthieu pose la question de la capitalisation. Aujourd’hui, la plupart des équipes consomment des fichiers de prompts et de contexte sous forme de Markdown. C’est un bon début, mais on peut faire mieux. Il présente un spectre de maturité en trois niveaux.
L’Assistant / Prompt Engineering : capitalisation sous forme de prompts et contexte, sous forme d’assistant (Copilot) ou de GPTs. Exemple : un assistant de conception d’architectures C4. Niveau de capitalisation faible.
Les Agent Skills : format Claude Skill (Markdown + Scripts + Assets), exécutable via IDE ou CLI agentique. Permet de l’automatisation avec supervision humaine. Exemple : un skill pour le refactoring de code. Capitalisation intermédiaire.
Le MCP (Model Context Protocol) : format d’API qui permet de mettre à disposition des agents des ressources, données ou processus complexes. Exemple : MCP Jira pour gérer et modifier les tickets directement depuis l’agent. Capitalisation maximale.
Pour visualiser ces choix, Matthieu introduit une matrice à deux axes : Automation-level (du Strategic Chat à l’Agentic IDE puis Agentic CLI) en ordonnée, et Scale (d’Individual à Collective : Assistant → Agent Skill → MCP → Custom) en abscisse. Des exemples concrets y sont positionnés : Assistant Architecte et Assistant Standards côté chat, Skill Retrodoc et MCP Jira côté IDE, Skill Audit Secu au niveau CLI, et Code Translate en Custom. Le message clé : en structurant l’expertise individuelle en artefacts réutilisables, on la transforme en pratiques collectives standardisées, auditables et automatisables à l’échelle.
Matrice Automation-level / Scale avec exemples concrets positionnés
Apprentissage 4 — Centraliser les contextes et les pratiques
Matthieu aborde un sujet plus avancé. Quand on a un SI composé de plusieurs microservices, chacun avec son propre AGENTS.md, ses docs/ et ses skills/, l’agent IA doit lire le contexte de chaque service indépendamment. C’est dommage, car beaucoup de contextes sont dupliqués et rien n’est centralisé.
Le problème : deux services avec des contextes isolés, que l’agent doit lire séparément
La solution proposée : adopter un monorepo avec un contexte partagé à la racine (AGENTS.md, skills/, docs/architecture/) qui fédère les patterns d’architecture communs, tandis que chaque service conserve son contexte spécifique (README.md, domain/, runbooks/). Le schéma montre que le contexte partagé se déverse dans chaque service, et que chaque service applique le même pattern d’architecture (ici l’architecture hexagonale).
La solution : monorepo avec contexte partagé et patterns d’architecture fédérés
L’avantage est exponentiel : une fois 10 microservices bien structurés avec un contexte partagé, le 11e sera considérablement plus simple à bootstrapper. C’est un processus avancé, pas facilement faisable immédiatement, mais extrêmement puissant une fois en place.
Apprentissage 5 — Changer ses réflexes
Pour conclure, Matthieu appelle à un changement de posture, résumé en quatre réflexes.
Se concentrer sur les méthodes, moins sur les outils. Les outils agentic évoluent toutes les semaines: Cursor, Copilot, Claude Code. Miser sur un outil spécifique, c'est prendre le risque d'être obsolète en six mois. Miser sur des pratiques solides: Architecture as Code, Living Documentation, Agent Skills, c'est construire quelque chose qui traverse les modes.
S'autoriser des projets réputés complexes avec une approche Agentic. Un gros refactoring qu'on repoussait depuis deux ans, une migration d'API, une rétro-documentation d'un legacy mal documenté, ces chantiers deviennent envisageables quand les agents disposent d'un contexte bien structuré. L'Agentic ne remplace pas l'effort de conception, mais il en démultiplie l'exécution.
Capitaliser sur les savoir-faire individuels et les scaler sur l'équipe. Le vrai risque avec l'Agentic, c'est que chaque développeur construise sa propre bulle de prompts et de contextes. La valeur émerge quand ces pratiques individuelles sont formalisées en Agent Skills réutilisables, revus collectivement et maintenus comme du code.
Responsabiliser les équipes dans l'usage de l'IA. C'est sans doute le point le plus sous-estimé. Avec les agents, les MR peuvent atteindre 5 000 lignes de changement en une session. La vélocité explose, mais le risque aussi. La réponse n'est pas de brider les outils, c'est de renforcer les garde-fous : linters, tests d'architecture automatisés, et une culture de revue de code adaptée à ce nouveau rythme.
Ce qu’on en retient
Ce talk de Matthieu Lagacherie est un retour d’expérience précieux sur une transformation encore en cours. Le message central est limpide : l’IA Agentic ne remplace pas l’architecte, elle le recentre sur sa vraie valeur: structurer la connaissance, définir les bons cadres, et orchestrer la collaboration humains-agents. La documentation n’est plus un livrable secondaire : elle devient le carburant de l’IA et donc le cœur du métier.
Les cinq apprentissages forment une feuille de route progressive : d’abord identifier les leviers (Architecture-as-Code, Living Documentation, Specification-as-code, SI Agentic), puis structurer le code et la documentation ensemble, ensuite capitaliser dans des formats partageables (Skills, MCP), centraliser le contexte à l’échelle du produit, et enfin changer ses réflexes au quotidien.
Ce qui est certain : dans un cycle où le code s'accélère, c'est la qualité du contexte qui devient le vrai différenciateur. Et ça, c'est le terrain de jeu de l'architecte.