Impact de l'IA sur l'état de l'art de l'ingénierie logicielle en 2026

Intro

2025 a été un tournant majeur dans l'usage de l'IA, bien au-delà du simple usage individuel.

Depuis 2020 nous sommes passé du monde de l’auto complétion à l’industrialisation :

• 2021 avec Github Copilot : un usage individuel, essentiellement tourné autour d'une autocomplétion évoluée.
• puis un usage dans le navigateur pour des tâches plus complexes, nécessitant de multiples allers/retours et copier-coller
• 2025 avec Claude Code, ou Windsurf et Cursor : un usage sur le poste du développeur à travers des assistants de code

En passant progressivement de quelques lignes produites par auto complétion, à des applications codées à plus de 90% par des assistants IA, les équipes de dev doivent faire face à une obligation d'industrialiser cette pratique au risque de grosses déconvenues.

Et plus que ça, à partir du moment où le métier de développeur change, c'est en réalité toute l'équipe de développement qui doit muter avec lui.

Ce n'est plus uniquement un simple sujet de tooling, mais un sujet d'industrialisation à l'échelle d'une équipe, tout comme les frameworks de tests automatisés ont changé la façon de créer du logiciel début des années 2000.

(On testait évidemment avant les années 2000, mais la façon dont on a réfléchi à l'automatisation de ces tests via les frameworks xUnit, l'avènement des usines logicielles (CI/CD) etc... est plus récente)

Dans cet article, on va explorer comment les équipes de devs se sont adaptées via des témoignages de plusieurs boîtes Tech qui ont participé à la rédaction en abordant :

• Le Context Driven Engineering, nouveau paradigme
• Spec/Plan/Act : le workflow de référence
• L’écosystème des AI Rules
• La gouvernance et l’industrialisation
• Les défis Humains

Context driven engineering

Si le terme vibe coding s'est imposé début 2025, on parlera plus volontiers désormais de Context driven engineering ou d'agentic engineering. L'idée n'est plus de donner un prompt, mais de fournir un contexte complet incluant l'intention ET les contraintes (coding guidelines etc...).

Le Context Driven Engineering vise à réduire la part non déterministe du processus et fiabiliser la qualité de ce qui est produit.

Avec le CDE, si la spec n'a pas toujours été bien vue, elle redevient un citoyen de première zone et devient une obligation avant le code.

Separate your process into two PRs:

• The PR with the plan.
• The PR with the implementation. The main reason is that it mimics the classical research-design-implement loop. The first part (the plan) is the RFC. Your reviewers know where they can focus their attention at this stage: the architecture, the technical choices, and naturally their tradeoffs. "It's easier to use an eraser on the drawing board, than a sledgehammer at the construction site"

Source : Charles-Axel Dein (ex CTO Octopize et ex VP Engineering chez Gens de confiance)

On retrouve cette même logique ici chez Clever Cloud :

Here is the paradox: when code becomes cheap, design becomes more valuable. Not less. You can now afford to spend time on architecture, discuss tradeoffs, commit to an approach before writing a single line of code. Specs are coming back, and the judgment to write good ones still requires years of building systems.

Source : Pierre Zemb (Staff Engineer chez Clever Cloud)

ou chez Google

One common mistake is diving straight into code generation with a vague prompt. In my workflow, and in many others’, the first step is brainstorming a detailed specification with the AI, then outlining a step-by-step plan, before writing any actual code.

Source : Addy Osmani (Director sur Google Cloud AI)

Bref, on retrouve désormais cette méthode un peu partout :

• spec
• plan
• act

Spec/Plan/Act

Spec : La spécification regroupe les cas d'usages : les intentions exprimées par l'équipe de développement. On peut l’appeler RFC (request for change), ADR (architecture decision record), ou PRD (Product requirement document) selon les contextes et les entreprises.

C’est le document de base pour démarrer un développement avec une IA. La spec est habituellement relue par les experts produits, devs ou pas.

L’usage d’IA n’est pas rare non plus à cette étape (Cf. plus loin dans l’article).

Mais le contexte ne se limite pas à cela. Pour limiter les initiatives malheureuses des IA, il faut également lui fournir des contraintes, les normes de développement, les outils à utiliser, les docs à suivre. On verra ce point plus loin.

Plan : Le plan d'implémentation liste l'ensemble des étapes pour implémenter la spécification. Cette liste doit être exhaustive, chaque étape doit être réalisable par un agent de façon autonome avec le contexte nécessaire et suffisant. C'est habituellement relue par des seniors (architecte, staff, tech lead etc... en fonction des entreprises).

Act : Il s’agit de l’étape d’implémentation et peut être répartie à des sessions agentiques.

Dans de nombreuses équipes, cette session peut se faire selon deux méthodes : *

• le mode copilote/pair programming avec une validation de chaque modification une par une
• le mode agent, ou le développeur donne l'intention puis vérifie le résultat (on verra comment plus tard)

On retrouve bien sûr des variations, comme par exemple chez Ilek qui détaille d’avantage la partie Act :

Nous en somme à la première phase de l’industrialisation qui est l’adoption. L’objectif c’est que d’ici la fin du trimestre tous les dev s’appuient sur ce framework et que l’utilisation des prompts/agents soit un réflexe. On vise donc une adoption de 100% d’ici fin mars. Notre workflow part du besoin et se découpe en plusieurs étapes qui vise à challenger les devs dans les phases de réflexion jusqu’à la validation du code produit. Voici la liste des étapes qu’on suit: 1- elaborate (challenge le besoin et interroge sur les cas limites, les choix techniques, l’architecture, etc.) 2- plan (propose un découpage technique, ce plan est fourni en sortie dans un fichier Markdown) 3- implement (Des agents vont réaliser les étapes du plan) 4- assert (un agent va valider que le résultat final répond aux attentes, lint, test, guideline) 5- review (des agents vont faire un review technique et fonctionnelle) 6- learn (mise à jour du context) 7- push (création de la MR sur gitlab) Tout ce processus se fait en local et est piloté par un développeur.

Cédric Gérard (Ilek)

Si cette méthode en 3 phases semble faire consensus, on voit pas mal d’expérimentations pour encadrer et renforcer ces pratiques, notamment avec deux outils qui reviennent régulièrement dans les discussions : Bmad et SpeckKit.

Pour avoir testé les deux, on peut aboutir assez facilement à une surdocumentation un peu verbeuse et un ralentissement du cycle de dev.

J'ai l'intuition qu'il faut éviter de reproduire numériquement des processus humains qui étaient déjà bancals. A-t-on vraiment besoin de tous les rôles proposés par BMAD par exemple ? J’ai eu l’impression de faire du SaFe en mode solo et ce n'était pas une bonne expérience :)

Ce qui est sûr, c'est que si la spec redevient reine, la spec nécessaire à une IA se doit d'être simple, sans ambiguïté. La verbosité peut nuire à l'efficacité des assistants de code.

L’écosystème des AI Rules

Si le mode agentique semble prendre le dessus sur le mode copilote, cela vient avec des contraintes supplémentaires pour s'assurer de la qualité. On veut absolument s'assurer :

• que l'implémentation respecte la spec
• que le code produit respecte les standards de l'équipe
• que le code utilise les bonnes versions des librairies du projet

Pour s'assurer de la qualité produite, les équipes fournissent le contexte nécessaire pour informer l'assistant de code des contraintes à respecter. Paradoxalement, malgré la mauvaise réputation du vibe coding et son usage auparavant réservé aux prototypes, le Context Driven Engineering remet les bonnes pratiques d'ingénierie habituelles (harnais de test, linters etc...) sur le devant de la scène. Sans elles, il devient impossible de s'assurer de la qualité du code et de l'architecture.

En plus de toutes les bonnes pratiques classiques, la plupart des systèmes agents viennent avec leurs propres concepts : le fichier de contexte général (agents.md), les skills, les serveurs MCP, les agents.

agents.md

Un assistant de code va lire plusieurs fichiers en plus de la spec qu'on lui fournit. Chaque assistant de code propose son propre fichier : Claude.md pour Claude, .cursorrules pour Cursor, windsurfrules pour Windsurf etc...

Il existe une tentative d'harmonisation via agents.md mais l'idée est toujours globalement la même : une sorte de README pour AI. Ce README peut s'utiliser de façon hiérarchique, on peut en effet avoir un fichier à la racine, puis un fichier par répertoire où c'est pertinent.

| agents.md
| 
` application 1
  | 
  ` agents.md 

Ce fichier contient les instructions à suivre systématiquement, exemple :

- l'interface est en anglais obligatoirement
- dans le backend nuxt (`server/api/`), on utilise TOUJOURS le client OpenAPI généré (`~~/server/utils/openapi`), jamais `$fetch` direct

et peut faire référence à d'autres fichiers.

Si tu dois travailler en kotlin, toujours charger le fichier rules/kotlin.md 

Avoir plusieurs fichiers permet à chaque agent de travailler avec un contexte réduit, ce qui améliore l'efficacité de l'agent en question (sans parler de l'économie sur les coûts).

Les skills, agents, serveurs MCP

En fonction des outils utilisés, on retrouve plusieurs notions qui ont chacun des usages différents.

Une skill explicite à un agent IA comment réaliser un type d'opération.

Par exemple, on peut lui donner les commandes à utiliser pour appeler certains outils de génération de code, ou de vérification statique.

Un agent peut être impliqué pour prendre en charge une tâche spécifique. On peut par exemple avoir un agent dédié à la documentation externe avec des instructions quant au ton à adopter, l'organisation recherchée etc...

Les serveurs MCP permettent d'enrichir la boîte à outils de l'agent IA. Cela peut être des accès direct à une documentation (par exemple la doc de Nuxt), voire à des outils pour consulter les infos d'un compte de test comme le MCP de Stripe.

Il est encore trop tôt pour le dire, mais on pourrait voir apparaître une notion de dette technique liée à l’empilement de ces outils et il est fort à parier que l’on verra des techniques de refactorings et de tests se profiler dans le futur.

La gouvernance et l’industrialisation

Avec l’apparition de ces nouveaux outils vient une question : comment uniformiser la pratique et profiter des bonnes pratiques de chacun ?

Comme le dit Benjamin Levêque (Brevo)

L'idée c'est : au lieu que chacun galère avec ses propres prompts dans son coin, on met en commun nos découvertes pour que tout le monde en profite.

Des Marketplaces d'entreprises

Une des premières réponses pour la mise en commun repose sur la notion de marketplace d’entreprise :

Chez Brevo, on vient de lancer une marketplace interne avec des skills et des agents. Ca nous permet d'uniformiser le code généré via l'IA (avec Claude Code), tout en respectant les standards définis par les "experts" de chaque domaine (langage, techno, etc.). Les 3 composants dans claude code : On transforme nos succès en Skills (instructions réutilisables), en Subagents (IA spécialisées) et en Patterns (nos meilleures architectures). Ne pas réinventer la roue : On passe d'une utilisation "au feeling" à une méthode systématique.

Benjamin Levêque et Maxence Bourquin (Brevo)

Chez Manomano on a aussi initié un repository afin d'y transposer nos guidelines et ADR sous un format machine friendly. On décline ensuite des agents et des skills que l'on va ensuite installer dans claude code / opencode. On a un outil de bootstrap de machine interne, on y a ajouté ce repo ce qui fait que tout les tech de la boite se retrouve outillés. C'est ensuite à chacun de référencer les règles ou skills qui sont pertinents en fonction des services. On a des skills typés intégration (utilisation de notre IAC interne pour ajouter X ou Y), d'autres qui sont des pratiques (faire une revue de code : comment faire du react a Manomano) et des commandes qui couvrent plus des orchestrations (tech refinement, implementation de feature avec revue). On observe aussi qu'il est difficile d'uniformiser les installations de MCP chez chacun, ce qui est dommage quand on voit l'impact de certains sur la qualité de ce qu'on peut produire (Serena a été cité et je rajouterai sequential-thinking). On en est au point ou on se demande comment garantir un env iso chez tout les dev, ou comment le rendre cohérent chez tout le monde

Vincent AUBRUN (Manomano)

Chez Malt, nous avons aussi démarré la mise en commun de commands / skills / AGENTS.MD / CLAUDE.MD. Classiquement, l'objectif des versions initiales est de partager un certain nombre de connaissances qui permettent à l'agent de ne pas repartir de zéro. Les propositions (via MR typiquement) sont revues dans le cadre des guildes (backend / frontend / ia). A noter qu'on se cherche encore beaucoup à l'échelle de l'engineering. Il est notamment compliqué de savoir si un élément partagé est vraiment utile au plus grand nombre.

Guillaume Darmont (Malt)

A noter qu’il existe des marketplace publiques, on peut citer :

• la marketplace Claude
• une marketplace par vercel

Attention cependant, il est obligatoire de relire tout ce que vous installez…

Parmi les méthodes de déploiement, beaucoup ont privilégié des outils customs, mais François Descamps de Axa nous cite une autre solution :

Pour le partage des primitives, nous explorons APM (agent package manager) de Daniel Meppiel. J’aime beaucoup le fonctionnement, il est assez facile d’utilisation et s’utilise pour la partie gestion de dépendances comme NPM.

Intégration dans la CI/CD

Malgré toutes les instructions fournies, il arrive régulièrement que certaines soient ignorées. Il arrive aussi que les instructions soient ambiguës et mal interprétées. C'est là où les équipes mettent en place obligatoirement des outils pour encadrer les IA :

• linting
• harnais de test
• revues de code

Si l'œil humain reste obligatoire pour tous les participants interrogés, ces outils eux-mêmes peuvent s'appuyer partiellement sur des IA.
Les IA peuvent en effet rédiger les tests. L'humain vérifie alors la pertinence des tests proposés.
Plusieurs équipes ont également créé des agents spécialisés dans la revue avec des scopes bien spécifiques : la sécurité, la performance etc...
D'autres utilisent des outils automatisés, certains directement branchés sur la CI (ou sur Github).

(je ne les cite pas mais vous pouvez les trouver facilement).

Liée à cette notion de CI/CD, une question qui revient souvent :

Il est également très difficile de savoir si une "amélioration", i.e. modification dans le fichier CLAUDE.MD par exemple, en est réellement une. Est-ce que la qualité des réponses sera réellement meilleure après la modif ?

Guillaume Darmont (Malt)

Est-ce que je peux évaluer un modèle ? Si je change mes guidelines, est-ce que l'IA génère toujours un code qui passe mes critères de sécurité et de performance ? Est-ce qu’on peut traiter le prompt/contexte comme du code (Tests unitaires de prompts).

A cela Julien Tanay (Doctolib) nous dit :

A propos de la question "est(ce que ce changement sur le skill le rend meilleur ou moins bon", on va commencer a regarder promptfoo et brainstrust (utilisé en prod pour l'IA produit chez nous) pour faire de l'eval dans la CI.(...) Par exemple avec promptfoo, tu vas vérifier, dans une PR, que pour les 10 variantes d'un prompt "(...) setup my env" le skill env-setup est bien trigger, et que l'output est correct. Tu peux vérifier l'appel du skill programmatiquement, et l'output soit via "human as a judge", ou plutot "LLM as a judge" dans le cadre d'une CI

L’ensemble des discussions semble indiquer que le sujet est encore en recherche, mais qu’il existe déjà des pistes de travail.

Les coûts

On avait un KPI principal qui était d'obtenir 100% d'adoption pour ces outils en un trimestre (...) Au début notre KPI principal c'était l'adoption, pas le coût.

Julien Tanay (Staff engineer chez Doctolib)

Le coût vient en effet souvent en seconde partie. Le schéma classique, c’est l’adoption, puis l’optimisation.

Pour maîtriser les coûts, il y a d'une part l'optimisation des sessions, qui passe par

• le fait de garder des fenêtres de sessions courtes, en ayant découpé le travail en petites étapes indépendantes.
• l'usage de la commande /compact pour garder uniquement le contexte nécessaire (ou le fait de flusher ce contexte dans un fichier pour reprendre une nouvelle session)

On retrouve par exemple ces conseils proposés par Alexandre Balmes sur Linkedin.

Cette maîtrise des coûts peut être centralisée avec les licences entreprises.
Cette bascule entre clé individuelle et clé entreprise fait parfois partie de la procédure d'adoption :

On une strat progressive sur les coûts. On fournit une clef d'api pour les nouveaux, afin de suivre leurs usages et payer au plus proche de la conso. Passer un seuil on les bascule sur des licences Anthropic enterprise car on estime que c'est plus intéressant pour les usages quotidiens.

Vincent Aubrun (ManoMano)

Sur le coût mensuel par développeur, les différentes discussions permettent de faire émerger 3 catégories :

La grande majorité oscille entre la catégorie 1 et 2.

La documentation, effet de bord positif des IA

Quand on parle de gouvernance, la documentation étant devenue le nouveau langage de programmation, elle redevient un citoyen de première zone.

On la retrouve dans les specs en markdown présent sur le projet, les ADR/RFC etc... Ces docs sont désormais maintenues en même temps que le code est produit.

Alors nous on a déclaré que le markdown c'était la source de vérité. Confluence en PLS :)

Julien Tanay (Doctolib)

Ce n’est plus un simple micro événement dans le cycle de dev du produit, géré parce qu’il le faut et rangé au placard. Les équipes les plus matures font désormais évoluer la doc pour faire évoluer le code, ce qui permet d’éviter le fameux syndrome des piles de documents d’entreprises obsolètes qui trainent sur un drive partagé.

Cela a de nombreux avantages, elle peut être utilisée par des agents spécialisés pour l'écriture de la doc utilisateur (la doc end user), ou être utilisée dans un RAG pour servir de base de connaissance, pour le support client, l'onboarding des nouveaux arrivants etc…

L'intégration de ce framework impacte la façon de gérer les incidents. Il offre la possibilité de debugger nos services avec des agents spécialisés qui peuvent s’appuyer sur les logs par exemple. Il est possible d’intérroger le code et la memory bank qui agit comme une documentation vivante.

Cédric Gérard (Ilek)

La propriété intellectuelle

L’un des sujets majeurs qui revient est évidemment la propriété intellectuelle. Il ne s’agit plus de faire de simples copier-coller dans un navigateur avec un contexte choisi, mais de donner accès à la codebase entière.

C’est une des grandes motivations de passer sur les licenses enterprise qui contiennent des clauses contractuelles de type “zero data training”, voire “zero data retention”.

En 2026 on devrait aussi voir apparaître l’AI act et la certification ISO 42001 pour auditer la manière dont les données sont collectées et traitées.

Dans les usages enterprise on note aussi des montages via des partenariats comme celui entre Google et Anthropic :

De notre côté, nous n'avons pas besoin d'allouer un montant à l'avance, ni d'acheter des licences, car nous utilisons les modèles Anthropic déployés sur Vertex AI d'un de nos projets GCP. Il suffit ensuite de faire pointer Claude Code sur Vertex AI. Cette configuration adresse également les problématiques de propriété intellectuelle.

Sur tous ces points, une autre piste semble être d’utiliser des modèles locaux. On peut citer Mistral (via Pixtral ou Codestral) qui propose de faire tourner ces modèles sur des serveurs privés pour garantir qu'aucune donnée ne franchit le firewall de l'entreprise.

J’imagine que ce serait également possible avec Ollama.

Cependant je n’ai rencontré qu’une seule entreprise qui travaillait sur cette piste pendant mes discussions. Mais on peut anticiper que l'essor des modèles locaux sera plutôt un sujet 2026 ou 2027.

Les impacts humains

Le recrutement

Si l'IA est désormais solidement implantée dans de nombreuses équipes, ses impacts dépassent désormais le cadre du seul développement.

On retrouve notamment des réflexions autour du recrutement chez Alan

Picture this: You’re hiring a software engineer in 2025, and during the technical interview, you ask them to solve a coding problem without using any AI tools. It’s like asking a carpenter to build a house without power tools, or a designer to create graphics without Photoshop. You’re essentially testing them on skills they’ll never use in their actual job. This realization hit us hard at Alan. As we watched our engineering teams increasingly rely on AI tools for daily tasks — with over 90% of engineers using AI-powered coding assistants — we faced an uncomfortable truth: our technical interview was completely disconnected from how modern engineers actually work.

Emma Goldblum (Engineering chez Alan)

La formation des juniors

Un des gros sujets porte sur la formation des juniors qui peuvent être rapidement en danger avec l'usage de l'IA. Ils sont en effet moins productifs désormais, et n'ont pas toujours l'expérience nécessaire pour challenger correctement le code produit, ou écrire correctement les spécifications. Une grande partie des tâches autrefois attribuées aux juniors est dorénavant monopolisée par les IA (code boiler plate, validation de formulaire, tâches répétitives etc...).

Cependant, toutes les équipes reconnaissent la nécessité d'embarquer les juniors pour ne pas créer un fossé d'expérience dans le futur.

Malgré cette prise de conscience, je n’ai pas vu d’initiatives spécifiquement sur le sujet qui viserait à adapter la formation des plus juniors.

L’accueil des nouveaux arrivants

Enfin l'accueil des nouveaux arrivants est bousculé par l'IA, notamment parce qu'il est désormais possible de les accompagner pour découvrir le produit

Certaines équipes ont un skill d'onboarding qui aide a setup l'env, fait un tour de la codebase, fait une PR d'exemple... Les gens sont créatifs*

Julien Tanay (Doctolib)

Par effet de bord, ce point est jugé facilité par les changements induits par l’IA, notamment aidé par le fait que les documentations soient mises à jour plus régulièrement et que l’ensemble des guidelines soient très explicites.

L’accompagnement vers un changement de métier

Un des éléments peu abordés reste l’accompagnement des développeurs face à une mutation de leur métier.

On déplace la valeur des développeurs de la production du code à la maîtrise du métier. Cela oblige à prendre beaucoup de hauteur. L’écriture du code, les pratiques comme le TDD sont des éléments qui participent au plaisir qu’on prend dans le travail. L’IA vient bouleverser ça et certain ne seront peut-être pas capable de s’epanouir dans cette évolution de notre métier

Cédric Gérard (Ilek)

La question n’est pas de savoir si le métier de développeur touche à sa fin, mais plutôt dans quelle mesure il évolue et quelles sont les nouvelles compétences à acquérir.

On peut comparer ces évolutions à ce qui est arrivé dans le passé lors des transitions entre les cartes perforées et la programmation interactive, ou avec l’arrivée des langages de plus haut niveau. Avec l’IA les équipes de développement gagnent en niveau d’abstraction, mais gardent les mêmes défis, identifier les bons problèmes à résoudre, trouver quelles sont les solutions technologiques adéquates, réfléchir en termes de sécurité, performance, fiabilité et de compromis entre tout cela.

Malgré tout, cette évolution n’est pas forcément bien vécue par tous et il devient nécessaire dans les équipes d’accompagner les personnes à considérer le développement sous un angle différent pour retrouver l’intérêt du métier.

Cédric Gérard nous met en garde également contre d'autres risques :

Il y a un risque sur la qualité des productions qui diminue. L’ia n’étant parfaite, il faut être très attentif au code généré. Cependant review du code ce n’est pas comme produire du code. La review c’est fastidieux et on peut très rapidement se laisser aller. A cela s'ajoute un risque de perte de compétence. Lire n’est pas écrire et on peut s’attendre à développer une capacité d’évaluation, mais un perdant petit à petit en créativité

Conclusion

2025 a vu l’essor de la programmation agentique, 2026 sera sans doute une année d’apprentissage en entreprise autour de l’industrialisation de ces outils.

Il y a des points dont je me réjouis, c'est le retour en force de la pensée système. Le "Context Driven Engineering" nous force à redevenir de bons architectes et de bons concepteurs produit. Si vous ne savez pas expliquer ce que vous voulez faire (la spec) et comment vous comptez le faire (le plan), l'IA ne vous sauvera pas ; elle produira juste de la dette technique à une vitesse industrielle.

Un autre effet de bord inattendu pourrait être la fin de l'ego coding, la disparition progressive de l'attachement émotionnel au code produit qui créait parfois des discussions compliquées, par exemple lors des revues de code. En espérant que cela nous rende plus critique et moins réticent à jeter du code et des fonctionnalités non utilisées.

Quoi qu'il en soit, la différence entre une équipe moyenne et une équipe d'élite ne s'est jamais autant jouée sur des compétences "anciennes". Savoir challenger une architecture, poser de bonnes contraintes de développement, avoir une bonne CI/CD, anticiper les failles de sécurité, et maintenir une documentation vivante seront d’autant plus critiques qu’avant. Et par expérience ce n’est pas si acquis que cela partout.

Maintenant, il reste des questions, il va falloir apprendre à piloter un nouvel écosystème d'agents tout en gardant le contrôle. Entre les enjeux de souveraineté, les questions autour des modèles locaux, la capacité à tester la reproductibilité et la qualité des prompts, l'explosion des coûts et la mutation du rôle de junior, nous sommes encore en pleine phase d'apprentissage.