2025, l'année où le développement logiciel a changé de paradigme
L'année 2025 a été une expérience en temps réel menée à l'échelle de toute l'industrie technologique : les capacités d'ingénierie logicielle de l'IA y ont été mises à l'épreuve face aux technologues humains. Et si l'année a commencé avec une IA paraissant toute-puissante, la transition du « vibe coding » vers ce qu'on appelle désormais le « context engineering » a démontré une chose : le travail des développeurs évolue profondément, mais il reste absolument critique.
Ce basculement se lit dans les radars technologiques que publient régulièrement les grands cabinets de conseil tech : on y voit émerger, édition après édition, des techniques et des outils conçus pour aider les équipes à mieux gérer le contexte fourni aux LLM et aux agents IA, et disparaître les paris sur la seule puissance brute des modèles.
Pris dans leur ensemble, ces signaux dessinent une direction claire, pour l'ingénierie logicielle comme pour l'IA en général : après des années où l'industrie a supposé que le progrès ne dépendait que de l'échelle et de la vitesse des modèles, il est désormais acquis que ce qui compte est la capacité à gérer le contexte efficacement. Mi-2026, ce constat n'est plus une intuition : c'est le socle des pratiques d'équipe.
Vibe coding : promesses initiales et antipatterns révélés
C'est en février 2025 qu'Andrej Karpathy a inventé le terme « vibe coding ». Lâchée presque en passant, l'expression a pris l'industrie d'assaut. Elle capture l'approche initiale que beaucoup ont adoptée avec les assistants IA : donner au modèle une direction générale, une « vibe » de ce que l'on veut, puis itérer jusqu'à ce que le résultat semble correct, l'équivalent logiciel d'improviser une mélodie sans partition.
Cette approche semble libératrice au début : plus de spécifications détaillées, plus de cas limites à anticiper, il suffit de laisser l'IA générer du code jusqu'à obtenir quelque chose de proche du besoin. Mais « proche » ne suffit pas pour du logiciel de production, et les antipatterns ont proliféré : complaisance envers le code généré, prompts toujours plus longs, dette de compréhension accumulée sur des bases de code que plus personne ne maîtrisait vraiment.
Le point d'inflexion du contexte
Chez Adservio, nous avons observé le même schéma chez nos clients. Les équipes commencent avec de petits prompts simples et obtiennent des résultats encourageants ; enhardies, elles en augmentent la taille et la complexité en s'attendant à ce que les modèles suivent proportionnellement. Ce n'est pas ce qui se passe : au-delà d'un point d'inflexion, ajouter du contexte dégrade la qualité des résultats. Les modèles se perdent, génèrent du code contradictoire ou se focalisent sur les mauvaises parties du contexte. C'est comme vouloir communiquer en criant plus fort, passé un certain volume, on ne résout plus un problème de clarté.
Context engineering : structurer le contexte comme une discipline
C'est ce constat qui a fait émerger le context engineering. En travaillant avec des assistants de codage agentiques comme Claude Code, fournir le bon contexte, ce que l'on appelle parfois le « knowledge priming »,s'avère décisif : les sorties deviennent plus cohérentes et fiables, les réécritures diminuent, la productivité réelle augmente.
Sélectionner, structurer, versionner, mesurer
Le context engineering ne se résume pas à écrire de meilleurs prompts. C'est une discipline d'ingénierie à part entière, qui repose sur quatre gestes : sélectionner le contexte réellement nécessaire à la tâche et exclure le bruit qui perturbe le modèle ; le structurer avec des formats et des hiérarchies que le modèle traite efficacement ; le versionner et le maintenir comme du code, avec revues et tests ; et mesurer son efficacité avec des métriques, plutôt que de juger « à l'œil » si les résultats s'améliorent.
Cette bascule a une conséquence organisationnelle : le contexte devient un actif d'équipe. Les fichiers d'instructions, les conventions documentées, les exemples canoniques ne sont plus des notes personnelles mais des artefacts partagés, revus et améliorés en continu, au même titre que la CI ou l'infrastructure as code.
IA générative et legacy : le paradoxe de l'abstraction
Les legacy codebases sont l'un des cas d'usage les plus puissants de l'IA générative : presque toutes les organisations possèdent ces systèmes écrits il y a des années, souvent par des développeurs partis depuis, avec une documentation rare ou inexistante. Là où il fallait des semaines de lecture de code et de rétro-ingénierie, un modèle correctement alimenté en contexte, structure du codebase, patterns récurrents, documentation disponible, produit des explications de haut niveau, identifie les composants critiques et suggère des stratégies de modernisation.
Décrire la fonction plutôt que montrer le code
La leçon contre-intuitive de nos expérimentations concerne le forward engineering : l'IA est plus efficace lorsqu'elle est davantage abstraite du système sous-jacent. Pour moderniser un système legacy, deux approches existent : donner au modèle un accès détaillé au code existant et lui demander de le transformer progressivement, ou lui décrire ce que le système fait, à un niveau fonctionnel, et lui demander de concevoir une solution nouvelle.
La seconde produit souvent de meilleurs résultats. Le code legacy est saturé de décisions historiques, de contournements techniques et de patterns obsolètes : trop enchaîner l'IA à ce code la conduit à reproduire ces patterns au lieu de repenser la solution. En fournissant un contexte fonctionnel de haut niveau, ce que le système doit faire, les contraintes métier, les exigences de performance, on élargit l'espace de solutions et on tire réellement parti des capacités génératives du modèle.
Agents autonomes : le contexte devient une question de sûreté
Le grand accélérateur de cette prise de conscience est la croissance des agents et des systèmes agentiques, que les organisations veulent à la fois développer comme produits et exploiter en interne. La différence fondamentale entre un chatbot et un agent tient à l'autonomie : un chatbot réagit dans une conversation, un agent initie des actions, appels d'API, requêtes en base, exécution de code, collaboration avec d'autres agents. Un chatbot qui comprend mal le contexte produit une mauvaise réponse ; un agent qui comprend mal le contexte prend de mauvaises actions : suppression de données, exposition d'informations sensibles, perturbation de systèmes en production.
AGENTS.md, mémoire d'agent et applications de référence
Un outillage s'est structuré autour de ce besoin. Le fichier AGENTS.md, devenu un standard de fait adopté par la plupart des assistants de codage, documente pour les agents, plutôt que pour les humains, les permissions, contraintes et conventions d'un codebase : répertoires modifiables, patterns à suivre, actions nécessitant une approbation humaine. Des systèmes de mémoire comme Mem0 permettent aux agents de capitaliser sur leurs interactions passées au lieu de traiter chaque tâche en isolation, et des outils comme Context7 injectent la documentation à jour des dépendances directement dans le contexte.
Nous avons aussi trouvé du succès en ancrant les agents de codage à une application de référence : plutôt que de décrire en mots comment l'organisation construit ses logiciels, on montre un exemple canonique qui incarne les standards. Chez Adservio, nous maintenons de telles références par type de projet, backend microservices, frontend React, pipeline de données, qui servent de vérité terrain aux agents comme aux équipes d'agents, dont l'orchestration réduit le fardeau de contexte porté par chaque agent individuel.
MCP, A2A, spec-driven development : les standards s'installent
L'espace a mûri à mesure que les standards se sont imposés. Le Model Context Protocol (MCP) est devenu le protocole de référence pour connecter LLM et IA agentique aux sources de contexte : créé par Anthropic, il a été confié en décembre 2025 à l'Agentic AI Foundation, fondation neutre hébergée par la Linux Foundation avec OpenAI, Google, Microsoft, AWS et Block parmi les co-fondateurs. Mi-2026, MCP dépasse les 97 millions de téléchargements mensuels de SDK et est adopté par tous les grands fournisseurs d'IA ; le protocole agent2agent (A2A), qui standardise les interactions entre agents, fédère de son côté plus de 150 organisations sous la même gouvernance.
L'histoire de la technologie enseigne que les standards ouverts finissent généralement par gagner : HTTP a battu les protocoles propriétaires, Git a remplacé les gestionnaires de versions fermés. La même dynamique se joue dans l'IA, au lieu d'écosystèmes fermés par fournisseur, les composants IA deviennent interopérables.
Spécifications partagées et spec-driven development
Côté pratiques, le spec-driven development a gagné une vraie traction, outillé notamment par des frameworks open source dédiés : au lieu de commencer par le code, on rédige des spécifications détaillées, tests, schémas, descriptions comportementales, que l'on fournit à l'IA comme contexte d'implémentation. L'approche force la clarté, fournit un contexte riche et crée une suite de vérification automatique ; elle interroge en revanche l'agilité traditionnelle. Nous privilégions une voie hybride : spécifications de haut niveau pour la structure, itération rapide pour les détails. Et les bibliothèques d'instructions partagées, curées en équipe, restent l'outil le plus rentable : les équipes qui réussissent ne laissent pas chaque développeur improviser ses prompts, elles capitalisent collectivement.
L'ingénieur logiciel, curateur de contexte indispensable
Le fait que la conversation soit passée des questions de vitesse et d'échelle au contexte replace les ingénieurs logiciels au centre du jeu. Le contexte est précisément là où les humains excellent : nous comprenons les nuances, les implications, les non-dits ; nous détectons les contradictions et posons les questions de clarification. Les modèles, aussi puissants soient-ils, absorbent d'énormes quantités d'information mais peinent à prioriser et à savoir instinctivement ce qui compte.
Les compétences qui font la différence
Le rôle évolue sans disparaître : orchestrer des systèmes incluant des composants IA plutôt qu'écrire chaque ligne à la main, diagnostiquer des interactions complexes entre modèles, agents et systèmes traditionnels plutôt que déboguer ligne à ligne. Les compétences clés : le context engineering lui-même, l'architecture de systèmes hybrides, l'évaluation de composants non déterministes, et la gouvernance des systèmes agentiques.
Paradoxalement, plus le codage s'automatise, plus la collaboration humaine devient critique. Les équipes les plus efficaces que nous accompagnons pratiquent des revues de prompts comme on pratique des revues de code, des rétrospectives sur ce qui a fonctionné avec l'IA, et documentent patterns et antipatterns en commun. Le contexte n'est pas un détail technique : c'est le pont qui relie l'intention humaine à l'action de l'IA, et maîtriser ce pont est le défi déterminant de l'ingénierie logicielle moderne. C'est aussi ce qui rend le métier plus intéressant : moins de code répétitif, plus d'architecture, de conception et de décisions à fort impact.
RÉCUPÉRER CET ARTICLE
Téléchargez l'article complet en PDF pour le lire hors ligne ou le partager.
RESTER INFORMÉ
Recevez nos prochaines analyses et retours d'expérience directement dans votre boîte mail.
