Dans nos équipes de développement, les réactions à l’arrivée des assistants IA pour coder ont été contrastées. Certains les ont adoptés au quotidien, comme un assistant pour pousser plus loin leurs réflexions et apporter plus de valeur. D’autres se sont montrés plus sceptiques sur l’usage dans des codebases qui tournent en production : risque de perte de qualité, et de perte de contrôle sur ce que l’agent génère.
Les deux points de vue sont défendables, mais depuis peu le débat se déplace. Il portait sur la qualité du code généré ligne à ligne ; il porte désormais sur ce qu’on peut déléguer entièrement à l’agent, et sur les méthodes de contrôle qualité qui vont avec.
Ce basculement n’est pas qu’une lecture interne. Des équipes open-source parmi les plus exigeantes sur la maintenabilité, comme la core team de TanStack, ont fait du code généré par IA une part normale de leur travail pour multiplier leur productivité, sur des librairies massivement adoptées en production. Le code généré n’est plus une hypothèse, c’est un fait.
Ce qui nous occupe cette année n’est donc plus de savoir si on adopte, mais de bâtir le contrôle qualité qui nous permet de déléguer avec confiance aux agents IA.
Trois modes d’usage de l’IA : manuel, assistant, délégation
Dans nos pratiques récentes, on distingue trois manières d’utiliser l’IA.
- En mode manuel, le développeur écrit le code et ne sollicite l’agent que ponctuellement.
- En mode assistant, l’agent propose au fil de l’écriture, le développeur accepte ou rejette chaque suggestion.
- En mode délégation, le développeur cadre la tâche et l’agent l’exécute en entier : plan, écriture, tests, revue.
Une confusion fréquente, qu’on a faite nous-mêmes : croire être passés à la délégation tout en étant restés en mode assistant. On attend les réponses de l’agent, on réexplique le contexte à chaque session, on relit chaque ligne comme si tout le code généré comportait le même risque.
Entre un bon développeur sans agent et le même avec une fenêtre de chat, on n’a pas observé de réel gain de productivité. Le saut de productivité s’est surtout vu en délégation, et il se joue avant l’écriture du code.
Pilier 1 : utiliser les agents requiert de renforcer les fondamentaux d’ingénierie logicielle
Le code a maintenant deux lecteurs
L’humain comprend par habitude, retient le contexte d’un projet à l’autre, tolère l’implicite. L’agent a une mémoire limitée d’une session à l’autre, une session a aussi un contexte limité. En dehors de ce qui est écrit dans ces fichiers l’agent ne tolère rien d’implicite. Pour être provocant, travailler avec un agent c’est un peu comme onboarder un nouveau développeur à chaque tâche : il sait coder, mais il redécouvre le projet, et tout ce qui n’est pas écrit, il doit le reconstituer.
Cette contrainte pousse à expliciter ce qui était déjà une bonne pratique dans les grandes équipes, sans être toujours documenté dans les plus petites : contrats entre modules, typage aux frontières, schémas partagés, fichiers d’instructions, règles transversales. Aucun de ces patterns n’est nouveau. Ce qui change, c’est qu’ils prennent une valeur immédiate en fournissant une structure claire pour qu’un agent puisse travailler sans ambiguïté.
En normalisant non seulement notre façon d’écrire votre code mais aussi l’approche agentique elle-même, un développeur change de projet sans tout réapprendre, ni redéfinir nos conventions du flux de développement, ni la façon de piloter les agents.
La configuration de l’agent, une nouvelle expertise
Bien configuré, un agent reproduit fidèlement les patterns du projet. Mal configuré, il invente une structure différente à chaque fois, plausible mais qui ne suit aucune convention. Configurer un agent, c’est décider, pour chaque tâche, ce qu’il voit et ce qu’il peut faire.
C’est la différence avec une expérience de chat type ChatGPT, où l’utilisateur réexplique son contexte à chaque échange. Le travail du développeur est l’inverse : mettre en place un système qui apporte le bon contexte à l’agent de façon systématique.
Concrètement, on ne charge pas toutes les conventions du projet à chaque session ; on utilise le scoping et les bons déclencheurs pour lui donner celles qui concernent la partie du code où il travaille.
Ce cadrage vaut aussi pour la sécurité : on restreint les droits de l’agent, et des gates automatisées refusent les écritures hors de son périmètre.
Les sous-agents poussent cette logique plus loin. Pour une sous-tâche, on lance un agent à part, avec son propre contexte et ses propres droits. Il fait son travail et ne renvoie que le résultat, sans encombrer la session principale. Et comme chacun est indépendant, on peut en lancer plusieurs en parallèle.
Un cas concret
Sur un projet récent, une douzaine de spécifications partageaient le même pattern : un side panel avec un graphique et un tableau, branché à chaque fois sur un schéma de données différent, vérifiable côté backend. À l’estimation, avec l’hypothèse d’un développement sans agent, on comptait une demi-journée par side panel, soit environ six jours. Le premier a été écrit à la main. On en a ensuite tiré un fichier d’instructions, une « Skill » : un mode d’emploi versionné que l’agent charge à la demande, qui porte le pattern et le recompose pour chaque contexte. Les onze autres ont été livrés en une demi-journée, tests inclus.
C’est là que la configuration débloque les gains sur le répétitif : sans elle, chaque variation diverge un peu et la dette s’accumule ; avec, l’agent reproduit fidèlement le pattern et la codebase reste cohérente.
La dérive, et la cohérence de la codebase
Sur une tâche simple et bien cadrée, un agent reste cohérent. Dès que la complexité monte, il dérive : la cohérence entre modules se relâche, le scope déborde, des edge cases inutiles s’ajoutent, de la complexité apparaît sans nécessité, l’existant est peu réutilisé, ou encore l’agent laisse du code mort ou non utilisé. Cette dérive est une caractéristique des modèles génératifs dès qu’ils opèrent sur des contextes étendus, à anticiper plutôt qu’à corriger au cas par cas.
Les fichiers d’instructions alignent l’intention au démarrage d’une session, mais ne suffisent pas à empêcher la dérive d’exécution. Le filet réel est ailleurs : dans des contrats stricts entre les modules. Typage rigoureux aux frontières, schémas partagés entre front et back, invariants métier protégés par des tests qui échouent en cas d’écart. L’agent peut écrire ce qu’il veut à l’intérieur d’un module ; il ne peut pas franchir la frontière sans casser un contrat. C’est ce contrat, maintenu par le développeur, qui tient la cohérence.
Sur l’API d’un de nos projets, le pattern de module est documenté : chaque module reproduit la même structure. Un script d’audit grep cette structure attendue et signale les écarts. Il fait remonter des cas précis : un module dont les DTO utilisent une librairie de validation différente de la convention, un autre dont une partie de la logique métier est posée hors de la couche service.
Pris un par un, ces écarts sont mineurs. Cumulés, c’est la cohérence de la codebase qui se défait, et un agent qui étend un de ces modules reproduit l’écart au lieu de la convention.
Un projet classique ralentit en grandissant parce que seul le code s’accumule ; quand les vérificateurs, les patterns documentés et les fichiers d’instructions s’accumulent aussi, on observe l’inverse sur des pans entiers du développement.
À ce stade c’est pour nous un objectif, pas un acquis : ça ne tient que si on a une forte cohérence et qu’on a investi dans les vérificateurs autant qu’on a produit de code. Sinon, l’agent amplifie le désordre, et la codebase devient vite difficile à maintenir.
Le critère de vérifiabilité
Un agent n’est fiable que s’il peut vérifier ce qu’il fait, et c’est l’outillage et la codebase qui lui en donnent les moyens. Un test qui échoue, un type qui ne compile pas : chaque erreur est un retour concret que l’agent exploite pour se corriger et réessayer, sans intervention humaine. Avec des outils lents, ou une codebase sans tests, sans typage et sans conventions, cette boucle de vérification se casse, et un meilleur modèle ne la répare pas : il accélère seulement la production d’un code qu’on devra reprendre.
Cela mène à notre critère pour déléguer. La question n’est pas « l’agent est-il assez bon pour faire ça », mais « est-ce que le résultat peut être vérifié ». Certaines tâches ont une justesse que l’agent constate seul : les types compilent, les tests passent, le contrat tient. Le code structurel et répété, le nettoyage de données, la génération de tests à partir d’une spec précise : on les délègue parce que la codebase prouve elle-même que le résultat tient. La boucle se ferme sans nous.
Cette vérification automatique couvre une chose précise : la justesse de contrat. Elle ne dit pas si l’architecture est la bonne, ni si une règle métier a été correctement interprétée. Ces jugements gardent besoin d’une relecture humaine. Déléguer recentre la revue : la CI valide la forme, l’humain valide l’intention. Tenir ce volume de relecture à l’échelle reste un sujet ouvert, on y revient plus bas.
Cette frontière de délégation n’est pas figée. Chaque test qui fige un comportement, chaque contrat typé à une frontière transforme une portion de code invérifiable en code vérifiable, donc délégable.
C’est au développeur d’étendre la surface sur laquelle l’agent peut vérifier son travail en autonomie.
Les domaines où le développeur garde la main
L’envers du critère : plusieurs domaines demandent que le développeur garde la main, pour apporter une expertise ou un contexte que l’agent ne peut pas découvrir seul.
Le choix des technologies et des librairies
On utilise l’IA pour accélérer la veille et notre apprentissage, mais on teste les librairies nous-mêmes et on intègre ces choix à notre formation technique interne. Sans ce contact régulier avec le code, on perdrait le développement de notre expertise et la capacité à cadrer ces décisions.
La conception d’une architecture complexe
Une architecture résulte d’arbitrages négociés avec le client, de contraintes métier, de systèmes externes à intégrer, d’un historique, d’un stade de maturité. Rien de cela n’est lisible dans le code seul ; sans ce contexte, une suggestion d’IA reste trop générique pour être actionnable.
L’analyse de dette technique
L’IA repère des mauvaises pratiques apparentes, mais ne sait pas pourquoi elles existent ni ce qu’elles impliquent. Sur un projet legacy, elle peine à distinguer ce qui compte vraiment, et génère beaucoup de bruit qu’un développeur doit trier.
La refonte de legacy
Un projet legacy n’a parfois ni tests, ni typage, ni conventions, aucun des garde-fous qui permettraient à un agent de modifier le code sans rien casser. Il faut d’abord poser ce filet. Sur un projet legacy à la stack vieillissante, on a mis en place Playwright et Vitest pour capturer le comportement du frontend avant de le refactorer. L’agent peut écrire une partie de ces tests, en faisant tourner le code et en enregistrant ses résultats. Mais c’est au développeur de dire quel comportement mérite d’être figé : tout ce qui tourne aujourd’hui n’est pas voulu, et un test qui capture un bug le protège au lieu de permettre de le corriger.
Une fois ce filet posé, la refonte avance par incréments. À chaque étape, on garde la possibilité de rebasculer sur le code legacy tant que le nouveau n’a pas fait ses preuves : on ne remplace jamais en bloc, on substitue morceau par morceau sous le contrôle des tests.
Au Web Engineering Summit, les équipes de monday.com ont présenté une refonte qu’elles projetaient sur huit ans, livrée en six mois avec cette approche.
La logique exacte et les calculs métier
Quand le résultat doit être juste à l’unité, calculs financiers, conditions réglementaires, logique d’autorisation, une erreur passe facilement inaperçue. Ces calculs, on les écrit à la main : ils sont intrinsèquement liés à des règles métier, et les écrire reste la façon la plus fiable de les assimiler et de les certifier. Une vérification automatique ne suffit pas ici : un test peut passer alors que le résultat est faux, si le résultat attendu inscrit dans le test est lui-même faux. Ce qui protège le calcul, c’est que le développeur tienne les cas et leurs résultats attendus, et une compréhension de l’implémentation assez solide pour la certifier. C’est la même règle que partout ailleurs : on délègue ce qu’on peut vérifier, et ici la vérification passe par cette compréhension.
Un mot sur les tests, parce que le terme recouvre deux choses. Décider quel résultat est juste, pour telle entrée telle sortie attendue : ça demande de connaître le métier, c’est au développeur de le faire. Écrire le code du test qui vérifie ce résultat : une fois le résultat attendu décidé, c’est de la mise en forme, l’agent s’en charge. Quand on parle de déléguer la génération de tests, il s’agit de cette seconde partie. La première, une fois écrite, ne disparaît pas : elle reste dans la codebase comme un contrôle que l’agent fait tourner ensuite.
Pilier 2 : l’effort du développeur se déplace en amont du développement dans la conception
Une architecture floue ne se rattrape pas avec un meilleur modèle
L’agent IA fonctionne mieux sur une architecture claire. Sur un front-end composable avec peu de dépendances entre composants, l’agent comprend ce qu’il manipule, et son code s’intègre proprement. Sur une architecture couplée, avec de la logique implicite et des dépendances croisées, il reproduit les patterns en place, y compris ceux qu’on voudrait retirer, et amplifie le désordre.
Un exemple
Sur une codebase en cours de modernisation, deux logiques de data-fetching coexistent : l’ancienne, en Redux Saga, et la cible, en TanStack Query. Cette coexistence est normale pendant un refactoring de modernisation. Le problème est que l’agent, sans direction explicite, étend le pattern qu’il rencontre le plus, donc l’ancien. La migration recule au lieu d’avancer. Le filet est une règle scopée par dossier qui pose la cible : le code neuf utilise TanStack Query, Redux Saga est gelé sur les portions de code qu’on ne veut pas moderniser. Une décision d’architecture, écrite sous la forme d’une règle, devient une contrainte qui va pousser l’agent à prendre la bonne direction.
C’est pour cela que l’effort se déplace vers la conception : l’écriture du code n’est souvent plus l’étape qui consomme le plus de temps. Une conception incomplète en amont coûte cher à rattraper en aval, surtout quand un agent multiplie la production de code dans une mauvaise direction.
L’agent comme sparring partner
Avant une tâche longue, un développeur chez nous passe par une phase d’alignement avec l’agent. Il répond à des questions de cadrage qui ne portent pas sur l’écriture du code, mais sur la traduction d’une spec en conception : frontières de modules, formats d’API, cas limites, comportement attendu en cas d’erreur. L’agent ne reçoit pas passivement des consignes, il pose ses propres questions et réclame des précisions. Il oblige le développeur à expliciter ce qu’il aurait laissé implicite.
Sur un projet récent démarré avec une architecture agentique, ce sont ces questions qui ont permis de mieux cadrer le travail avant de coder.
Ce cadrage produit une spec écrite que l’agent reprend pour exécuter : le scope est fixé, les cas limites et les comportements d’erreur sont décidés. Si un point reste ouvert, l’agent ne le devine pas, il s’arrête ou il décide à notre place. C’est la même règle que pour le code : ce qui n’est pas écrit, il doit le reconstituer.
Deux exemples réels :
- Le premier, une contradiction dans la spec : une échelle de sévérité décrite à deux endroits du document, six niveaux de couleur dans le texte d’une user story, cinq dans le tableau de spécification plus bas. Lequel fait foi, et le sixième niveau, on le supprime ou on le range où ? Tant que ce n’est pas réglé, le composant ne peut pas être codé.
- Le second, un trou : chaque carte affiche « dernière mise à jour il y a X minutes » ; si la donnée date de deux jours, écrit-on « il y a 2880 minutes », bascule-t-on sur une date, grise-t-on la carte, et à partir de quel seuil la donnée est-elle considérée comme périmée ? La spec donnait le format, jamais la limite.
- Conséquence directe : la qualité de ce dialogue dépend du jugement du développeur. Avec peu d’expertise, on subit l’agent et on accepte les choix qui passent. Avec de l’expertise, on le pilote, on refuse des suggestions, on en impose d’autres.
Pour que cette expertise soit au rendez-vous, on a renforcé la formation et la R&D interne. On catalyse le partage de connaissances : une documentation d’architecture tenue au niveau de l’entreprise, qui aligne les équipes et où les agents vont chercher des configurations dans un registre commun amélioré en continu. Ce registre est une dépendance interne, et on la choisit délibérément : c’est un actif d’équipe, versionné et documenté, pas un produit tiers qu’un fournisseur fait évoluer sans nous.
Les défis encore ouverts du développement agentique
S’il fallait refaire le chemin depuis 2025, on aurait moins formé notre opinion en testant des outils, et plus en réfléchissant à ce que ce paradigme impliquait pour l’ingénierie de nos systèmes et pour la dynamique d’équipe.
Les agents IA arrivent avec leur lot de questions et de défis, dans des flux qui marchaient bien jusqu’ici. Voilà quelques exemples observés chez nous.
Le piège du « ça marche »
Avant, produire du code qui marche exigeait de comprendre le système qu’on touchait : la compréhension venait avec le travail. L’agent rompt ce couplage. Le code peut marcher, que le développeur ait compris ou non. Le risque est réel : l’expertise se nivelle en surface, et chacun peut glisser vers une posture passive, simple validateur de l’output d’un agent.
On l’observe au recrutement et en équipe. Au recrutement, des candidats qui affirment « l’IA code mieux que nous » : le signal d’alerte n’est pas l’usage de l’IA, c’est l’abandon du jugement sur sa sortie. En équipe, des développeurs solides sur les fondamentaux au moment de l’embauche qui, après plusieurs mois d’usage intensif de l’IA, ont laissé ces fondamentaux s’éroder. Le « ça marche » arrive vite ; dès que la complexité monte, refacto inter-modules, edge cases métier, performance, le code livré sans la maîtrise qui va avec ne tient pas, et la charge retombe sur ceux qui gardent une compréhension complète de la codebase.
C’est pourquoi on évalue un développeur sur deux fronts : ses fondamentaux et sa maîtrise d’une architecture agentique. L’un ne remplace pas l’autre. On y aide en faisant circuler les développeurs entre projets plutôt qu’en les isolant sur un seul, pour que chacun reste exposé à des contextes variés et confronte sa frontière de délégation à celle des autres.
Le travail en équipe sous IA
Chaque développeur place la frontière de ce qu’il délègue à un endroit différent, selon ses connaissances et son jugement. Tant qu’elle est définie individuellement, elle crée des frictions. Une tâche faite par un développeur peut être perçue par un pair comme « faite par l’IA » ; le coût se déplace alors vers le reviewer, qui fait un effort manuel après un travail automatique.
Dans le même mouvement, du bruit s’accumule dans le backlog : l’agent rend trivial de proposer des évolutions d’architecture, des refactos, trois edge cases là où un seul suffisait. Chaque proposition prise isolément est défendable ; c’est l’alignement de l’équipe sur ce qui mérite d’être codé qui se perd. Le triage des tickets reprend ici l’importance qu’il avait perdue : c’est le moment où l’équipe arbitre ensemble ce qui entre dans le scope et ce qui en sort. On expérimente d’en confier une partie à l’agent, repérer les tickets en double, regrouper les bugs d’une même cause, mais la décision reste collective.
On a remarqué que discuter explicitement de cette frontière débloque ces situations. Tant que la question reste « pour ou contre l’IA », chacun campe sur sa position et le débat tourne en rond. Ramenée cas par cas, ce qu’on délègue ici, ce qu’on garde là, la discussion sort du dogme et fait avancer les pratiques.
Adopter l’IA sans repenser le flux de travail
Le risque est d’adopter le développement agentique sans revoir sa façon de travailler. Trois travers qu’on observe quand le processus ne change pas avec les outils : étendre sa journée pour attendre les réponses de l’agent, faire tourner plusieurs sessions en parallèle « pour gagner du temps », laisser le scope déborder parce que l’agent peut absorber.
On observe un point commun dans les retours d’expérience : une charge perçue plus élevée, sans que personne n’ait demandé aux équipes de faire plus. Elles le font parce que l’IA rend « faire plus » accessible, et souvent immédiatement gratifiant. Le mécanisme est auto-renforçant : l’IA accélère, ce qui augmente les attentes de rapidité, ce qui élargit le scope, ce qui augmente encore la charge. C’est une limite qu’on prend au sérieux : un gain de productivité qui se paierait en surmenage n’est pas un gain net, et on ne le compte pas comme tel.
On ne l’a pas résolu, on agit sur le flux. L’IA rend techniquement possible de coder le soir ; pour les humains, on ne l’encourage pas. En revanche, on laisse tourner des sessions automatiques la nuit, sur des tâches scopées et vérifiables, que les développeurs reprennent le matin. À la reprise, les contrats et les tests ont déjà tranché la justesse de forme ; le développeur contrôle l’intention et le périmètre, sans relire ligne par ligne. L’équipe de nuit, c’est l’agent.
Ce qu’on prépare
L’enjeu technique des prochains mois se concentre sur trois chantiers.
La revue à l’échelle
À ce volume de code généré, la relecture ligne par ligne ne tient plus, et on n’a pas encore tranché le système cible. Les pistes : concentrer l’attention humaine là où elle tranche, le typage des interfaces, les frontières de modules, l’intention d’un changement. La CI valide déjà la forme ; il reste à outiller la revue d’intention.
Ce volume pèse aussi sur la chaîne d’intégration : plus de revues de code, c’est plus de CI à faire tourner, et un pipeline qui traîne annule une partie du gain. On agit des deux côtés. En amont, on limite le bruit pour ne pas ouvrir trois revues de code là où une suffit, ce qui rejoint le triage des tickets. En aval, on s’appuie sur la mise en cache pour ne réexécuter que ce qui a changé et garder la CI rapide.
L’orchestration d’agents
Les sessions de nuit sur des tâches scopées et vérifiables sont un premier pas. La suite : des agents plus autonomes et routiniers sur la codebase, qui itèrent sur une tâche jusqu’à ce qu’elle soit réellement terminée, enchaînent sur la suivante, et ne remontent que ce qui demande un arbitrage humain.
L’extension aux autres métiers
Ce changement ne s’arrêtera pas aux développeurs : il gagne déjà les métiers avec qui on construit, BA, design, QA, dont le travail s’articule directement avec le nôtre et qui sont exposés aux mêmes enjeux de qualité et de volume.
Ce que l’architecture agentique déplace dans nos projets
Concrètement, ce cadre déplace trois choses dans notre façon de travailler.
Le démarrage d’un projet est plus rapide : structure initiale, routes, services, premiers écrans tirés du design system, harnais de tests, ce qui prenait une dizaine de jours tient maintenant en quelques jours, à condition d’avoir les fondamentaux et des opinions techniques prêtes à déployer.
Les changements simples peuvent être automatisés : ce qui ne touche pas à l’architecture, une traduction, la gestion d’une erreur, l’ajout d’un champ dans un formulaire, en somme un pattern décliné, peut être traité avec un simple contrôle du développeur.
Le temps gagné sur l’exécution répétitive part dans la conception, les arbitrages structurants, les revues d’architecture, le traitement de la dette technique, la documentation : ce qui ne tenait pas dans le budget devient possible.
Le logiciel a toujours vieilli dans le même sens : plus une codebase grandit, plus chaque changement coûte. Le développement agentique donne un moyen d’inverser cette courbe. Quand le projet accumule, avec le code, ses vérificateurs, ses patterns documentés et ses fichiers d’instructions, chaque mois étend la surface délégable et rend le suivant plus rapide. Cette courbe ne s’inverse pas en pilote automatique : la boucle tient parce qu’un développeur cadre chaque tâche, tient les contrats et décide de ce qui mérite d’être figé. C’est l’objectif qu’on s’est fixé.
Les modèles continueront de s’améliorer, et chaque amélioration sera disponible pour tout le monde le même jour. Ce qui ne se télécharge pas, c’est ce qui s’accumule chez nous : une codebase vérifiable, des contrats tenus, des conventions outillées, et des développeurs qui savent où poser leur frontière de délégation et comment la faire avancer. C’est sur ces deux versants, l’ingénierie et le jugement, qu’on investit.
On livre non seulement une application qui tient en production mais aussi sur laquelle des agents pourront continuer à accélérer le développement de fonctionnalités sans dégrader la qualité.
