1. Introduction

Pendant la plus grande partie de l’histoire du logiciel, la ressource rare était l’écriture. Le métier d’un développeur se mesurait à sa capacité à transformer une intention en code correct, et les heures passaient à taper, à chercher des références, à assembler des bibliothèques, à corriger les petites erreurs que révélaient les erreurs de compilation et les tests en échec. Un agent de codage compétent supprime l’essentiel de cela. Donnez-lui une instruction claire et l’accès à une base de code, et il produira un changement fonctionnel en quelques minutes, dans des idiomes qu’il a vus un million de fois, avec le code répétitif déjà correct. Le nom familier de cette façon de travailler, popularisé début 2025, est le vibe coding : décrire ce que l’on veut et laisser le modèle le produire, en se guidant sur les résultats plutôt qu’en écrivant chaque ligne. C’est véritablement un changement d’ordre de grandeur, et il est facile de le prendre pour toute l’histoire.

Ce n’est pas toute l’histoire, car faire apparaître du code n’a jamais été la partie difficile du logiciel, seulement la partie laborieuse. Les parties difficiles sont de décider quoi construire, et de savoir que ce qui a été construit est réellement juste, sûr et apte à tourner. Celles-ci ne deviennent pas moins coûteuses quand la génération le devient ; si tant est, elles deviennent plus difficiles, car il y a désormais bien plus de code à comprendre, produit plus vite qu’une personne ne l’aurait écrit, par un auteur qui est sûr de lui même lorsqu’il a tort. Le goulot d’étranglement du développement logiciel se déplace. Il se tenait autrefois à la génération, la vitesse à laquelle une équipe pouvait écrire du code correct. Avec un agent, il se tient à la vérification : la vitesse à laquelle une équipe peut être sûre que le code est correct et le laisser passer.

Cet article porte sur la conséquence de ce basculement pour l’outillage, et il est délibérément concret. Si la vérification est la contrainte, alors la chose la plus précieuse qu’un dispositif assisté par IA puisse faire n’est pas de générer plus vite, c’est d’aider une équipe à vérifier plus vite et plus sûrement, en rattrapant les erreurs de l’agent à peu de frais et tôt. Nous décrivons la chaîne précise que nous, chez Nashua, utilisons pour construire et exploiter notre propre produit, la Nashua 360 Enterprise Platform — Claude Code comme agent, GitHub comme colonne vertébrale versionnée et garde-fou de revue, Vercel pour une prévisualisation active de chaque changement, Next.js comme framework applicatif, et Postgres comme base de données — et nous entrons dans le fonctionnement réel de chaque pièce, car c’est dans le détail que réside la valeur. Chaque maillon gagne sa place en resserrant une boucle ou en ajoutant un garde-fou, non en étant individuellement astucieux.

La contribution est un argument et une recommandation étayée, non un banc d’essai. La section 2 expose ce que l’IA a changé et ce qu’elle n’a pas changé, et situe le goulot d’étranglement. La section 3 présente la chaîne comme une boucle (figure 1), établit que pour le travail assisté par agent best-of-breed veut dire conventionnel, et explique pourquoi des garde-fous indépendants se composent. Les sections 4 à 9 reprennent tour à tour les cinq pièces et entrent dans leurs rouages, y compris l’architecture d’exécution qu’a réellement un déploiement (figure 2) et la partie qui surprend, à savoir qu’un changement peut désormais être lancé et revu depuis un téléphone. Les sections 10 à 12 traitent du garde-fou humain et de ses modes de défaillance, des coûts réels, et de la manière dont la chaîne tourne en pratique. La question tout du long est la suivante : une fois qu’un agent sait écrire le code, que doit mettre une équipe autour de lui pour qu’écrire vite ne signifie pas livrer faux ?

2. Ce que l’IA a changé, et ce qu’elle n’a pas changé

2.1 Le basculement

Le changement qu’apporte un agent se dit le mieux avec précision. Ce n’est pas que la machine comprend désormais le problème ; c’est que le coût de production d’une implémentation plausible, souvent correcte, d’un changement bien spécifié s’est effondré. Un développeur qui aurait passé un après-midi sur une fonctionnalité peut en avoir une première version dans le temps qu’il faut pour la décrire, et peut jeter plusieurs versions à peu de frais. Le mode de travail passe de la rédaction à la direction : énoncer l’intention, lire les résultats, corriger la trajectoire. C’est un véritable levier, et une équipe qui le refuse sera distancée.

2.2 Pas de solution miracle

Le changement est lui aussi borné, et la borne est ancienne. Brooks (1987) a tracé la distinction qui gouverne encore ici : la complexité accidentelle du logiciel, le labeur imposé par nos outils et nos langages plutôt que par le problème, peut être attaquée et réduite, mais la complexité essentielle, comprendre le problème et spécifier une solution correcte, ne peut être automatisée, parce qu’elle est le problème. Un agent de codage est l’attaque la plus puissante jamais construite contre la complexité accidentelle : il absorbe la syntaxe, le code répétitif, les recherches d’API, les idiomes. Il ne fait rien contre l’essence. Savoir ce dont le métier a besoin, décider de la bonne conception, et établir qu’un changement donné répond réellement au besoin sans casser autre chose, restent un travail humain, et c’est le travail qui a toujours été difficile.

2.3 La vérification devient la contrainte

Mettez les deux ensemble et la conclusion suit. La génération, la partie accidentelle, est désormais rapide et bon marché. La vérification, là où vit l’essence — que ce changement est correct, qu’il fait ce qui était voulu, qu’il n’a rien cassé, qu’il est sûr de l’exposer — ne l’est pas. Dans tout pipeline, le débit est fixé par l’étape la plus lente, et lorsque la génération accélère au-delà de la vérification, la vérification devient la contrainte qui lie. Une équipe qui peut générer dix changements par jour mais n’en vérifier que deux en livrera deux, et accumulera un arriéré de code non vérifié qui est un passif, non un actif. Pire, un agent produit un travail assuré et superficiellement correct, de sorte que le coût de la sous-vérification, de fusionner ce qui paraît juste et ne l’est pas, s’élève exactement à mesure que la tentation de le faire s’élève. Le reste de cet article porte sur la construction d’une chaîne dont la mission est d’élever le plafond de vérification et de rendre la sous-vérification difficile.

3. La chaîne, et pourquoi le conventionnel l’emporte

3.1 La boucle

Un bon dispositif assisté par IA est une boucle, non un outil. La figure 1 dessine celle que nous utilisons. Un développeur énonce une intention. Claude Code, l’agent, la transforme en un changement sur une branche, et non sur le code en production. Le changement devient une pull request GitHub, où deux garde-fous automatisés s’exécutent sans l’attention de quiconque : le vérificateur de types et la suite d’intégration continue. Vercel construit la branche en un déploiement de prévisualisation réel et actif, une copie complète de l’application avec le changement en service, accessible à sa propre URL. Un humain revoit le changement, lisant le diff et parcourant la prévisualisation, sur un poste de travail ou, de plus en plus, sur un téléphone. Alors seulement est-il fusionné dans la branche principale, que Vercel déploie en production, adossée à Postgres. Le résultat alimente l’intention suivante. Tout l’intérêt du schéma est que l’agent occupe une seule case ; toute autre case est une boucle qui se referme ou un garde-fou qui rattrape, et c’est de là que viennent la sûreté et la vitesse.

3.2 Best-of-breed veut dire conventionnel

La façon habituelle de choisir des outils est de les classer par puissance et de prendre le plus capable. Pour une chaîne assistée par agent, le critère est différent, et c’est l’idée la plus utile de cet article. Un agent écrit le mieux les outils qu’il a le plus vus. Sa compétence sur un framework ou une base de données est fonction de la quantité de code correct utilisant cet outil qui se trouvait dans son entraînement, et cette quantité suit la popularité de l’outil, sa documentation et la stabilité de ses conventions. Un outil répandu, bien documenté et riche en conventions n’est donc pas seulement un choix humain sûr ; c’est le choix sur lequel l’agent est le plus capable et le moins susceptible d’inventer une API qui n’existe pas. L’effet se compose : les outils populaires reçoivent davantage de code généré par des agents, qui fonctionne, ce qui renforce leur popularité. Pour le développement assisté par IA, best-of-breed et le plus conventionnel ont convergé, et chaque outil du tableau 1 a été choisi dans cet esprit. C’est aussi une mise en garde : le framework exotique qu’un expert humain saurait manier brillamment est souvent précisément là où un agent est le plus faible, parce qu’il en a vu le moins.

3.3 Pourquoi des garde-fous indépendants se composent

La chaîne ne fait confiance à aucune vérification isolée. Elle vérifie un changement à travers plusieurs garde-fous qui examinent des choses véritablement différentes : le vérificateur de types contrôle les formes, les tests d’intégration continue contrôlent le comportement, le déploiement de prévisualisation montre le résultat en fonctionnement, et le relecteur humain juge l’intention. Parce que les garde-fous sont largement indépendants, leurs manquements se multiplient plutôt qu’ils ne s’additionnent : un défaut n’atteint la production que si chaque garde-fou manque de le rattraper, de sorte que quatre garde-fous modestes qui rattrapent chacun l’essentiel de ce qu’ils voient ne laissent passer qu’une petite fraction du produit de ce qu’ils manquent. C’est le principe de défense en profondeur, connu de longue date dans l’ingénierie de la sûreté comme la superposition de barrières imparfaites (Reason, 2000), et il a un corollaire pratique tranchant. Retirer ou affaiblir un garde-fou — sauter la prévisualisation, désactiver un type strict, approuver sans lire — n’ajoute pas un peu de risque ; cela multiplie le taux d’échappement par l’inverse de ce que ce garde-fou rattrapait autrefois. La façon la moins coûteuse de rester en sûreté est de maintenir honnêtes plusieurs garde-fous différents et imparfaits, ce qui est exactement ce que la chaîne est agencée pour faire.

4. L’agent : comment Claude Code s’insère

Claude Code est l’agent : un outil qui lit la base de code, écrit et modifie des fichiers, exécute des commandes, lance les tests et ouvre des pull requests, en travaillant à partir d’une instruction et en se corrigeant au regard des résultats qu’il observe. La manière dont il est exécuté importe davantage que la capacité brute du modèle, et trois choses à son sujet méritent l’attention d’un praticien.

La première est le contexte. Un agent ne vaut que ce qu’il sait de votre base de code, et l’artefact au plus fort levier est un fichier de conventions versionné, dans notre cas un CLAUDE.md de projet, qui indique à l’agent les règles de la maison : comment le projet est agencé, comment exécuter le vérificateur de types et les tests, quoi déployer et comment, ce qu’il ne faut jamais toucher. L’agent le lit à chaque exécution, de sorte qu’une correction écrite une fois cesse de se répéter. Autour de lui s’étend une surface plus large : des skills réutilisables pour les tâches répétées, des hooks qui s’exécutent lors des appels d’outils pour imposer mécaniquement une règle, et des serveurs MCP qui donnent à l’agent un accès typé aux systèmes extérieurs, GitHub parmi eux, de sorte qu’il peut ouvrir et mettre à jour des pull requests comme des actions de premier ordre plutôt que par extraction d’écran. L’ingénierie du contexte — décider ce que l’agent doit savoir et pouvoir faire — est le vrai travail de son adoption, et c’est de l’hygiène logicielle ordinaire : écrire les conventions, rendre les vérifications exécutables, garder la surface petite.

La deuxième est que l’agent s’exécute dans la boucle plutôt qu’isolément. On attend de lui qu’il exécute lui-même le vérificateur de types et les tests, qu’il lise ce qu’ils rapportent et qu’il le corrige, avant qu’aucun humain ne regarde, de sorte que les garde-fous automatiques de la chaîne soient déjà au vert au moment où une pull request est ouverte. Pour les tâches plus lourdes, il peut répartir le travail entre des subagents qui portent chacun leur propre contexte et rendent compte, ce qui garde le fil principal concentré et le contexte propre. La discipline consiste à laisser la rétroaction rapide et bon marché — les types et les tests — se produire à l’intérieur de la boucle propre de l’agent, et à réserver la rétroaction lente et coûteuse — l’humain — pour la fin.

La troisième est où il s’exécute. Au-delà du terminal, Claude Code s’exécute comme une session cloud accessible depuis une application mobile, ce qui change la forme de la journée de travail. Un changement peut être lancé depuis un téléphone en chemin quelque part, laissé à tourner dans le cloud, et sa pull request et sa prévisualisation revues et approuvées plus tard depuis le même téléphone. Nous y tenons délibérément, non parce que le travail mobile est une nouveauté mais parce qu’il raccourcit la boucle : l’écart entre remarquer quelque chose et lancer le changement, et entre un changement prêt et quelqu’un qui l’approuve, se réduit d’heures à minutes, ce qui, dans un monde lié par la vérification, est précisément l’écart qui vaut la peine d’être comblé.

5. La colonne vertébrale : GitHub

GitHub est la partie de la chaîne qui rend tout le reste sûr, et c’est la moins glorieuse. Il détient la source unique de vérité, le dépôt, et il impose la règle sur laquelle repose tout l’argument : la branche principale, celle qui part en production, est protégée, et ne peut être atteinte que par une pull request qu’un humain a approuvée et dont les vérifications de statut requises ont réussi. L’agent ne modifie jamais directement le code de production ; il propose, sur une branche, et la proposition est un diff qu’un humain peut lire et qu’une machine peut tester.

Les vérifications requises sont là où vivent les garde-fous automatiques. Sur chaque pull request, GitHub Actions exécute la suite sur laquelle nous insistons avant toute fusion : le vérificateur de types, le linter, la suite de tests et une compilation de production, chacun un statut requis qui bloque le bouton de fusion jusqu’à ce qu’il soit au vert. Parce qu’ils sont imposés par la plateforme plutôt que par la discipline de quiconque, ils ne peuvent être sautés dans la précipitation, et parce que l’agent sait qu’ils s’exécuteront, il les satisfait d’abord. La pull request est l’unité de changement : petite, autonome, relisable individuellement et réversible individuellement, ce qui maintient la revue peu coûteuse et l’historique lisible. Et parce que chaque changement est un commit doté d’un auteur et d’un message, l’historique est une piste d’audit et l’annulation est totale : tout ce que l’agent a fait peut être vu, attribué et annulé. Un agent de codage est un acteur rapide, puissant et faillible, et GitHub est la structure qui rend sûr de lâcher un tel acteur, en garantissant que rien de ce qu’il fait n’est non revu, non testé ou irréversible.

6. Les yeux : Vercel

Lire un diff vous dit ce qui a changé ; il ne vous dit pas ce que fait le changement. Vercel comble cet écart en construisant chaque pull request en un déploiement de prévisualisation : une instance complète, isolée et active de l’application avec le changement appliqué, à sa propre URL, créée automatiquement et mise à jour à chaque push. C’est le garde-fou qui rattrape ce que les types et les tests ne rattrapent pas — la mise en page qui a cassé, le parcours qui a gagné une étape de plus, la chose techniquement correcte et fausse à l’usage — et c’est pour l’essentiel la raison pour laquelle la chaîne peut avancer vite sans avancer à l’aveugle. Un relecteur, et l’agent, parcourent le résultat réel plutôt que de l’imaginer à partir du code.

Ce qui rend la prévisualisation digne de confiance, c’est qu’elle est une véritable compilation de toute la pile, non une maquette (figure 2) : le même framework, le même runtime, ses propres variables d’environnement, et, bien faite, sa propre base de données isolée ou dérivée, de sorte que la solliciter ne peut toucher aux données de production. Les déploiements sont immuables : chacun est une compilation distincte et adressable, de sorte que promouvoir une prévisualisation revue en production est un déplacement de pointeur plutôt qu’une recompilation, et une mauvaise mise en production est un retour arrière instantané vers le déploiement immuable précédent plutôt qu’un correctif à chaud frénétique. Lors de la fusion dans la branche principale, la même machinerie qui a construit la prévisualisation construit la production, de sorte que ce qui a été revu est ce qui part en production. Dans le modèle de cette chaîne, les déploiements de prévisualisation sont un garde-fou de vérification peu coûteux et automatique, au taux de rattrapage élevé pour une classe de défauts qu’aucun autre garde-fou ne voit.

7. Sans couture grâce à git : pourquoi les trois s’accordent

La raison pour laquelle Claude Code, GitHub et Vercel ressemblent moins à trois outils qu’à un seul système, c’est qu’ils partagent une interface unique, et cette interface est git. La sortie naturelle de Claude Code n’est pas un déploiement ; c’est une branche et une pull request. Le rôle de GitHub est de stocker ces commits, d’exécuter les vérifications et de porter la revue. Vercel surveille le dépôt et transforme chaque branche en une prévisualisation et la branche principale en production. Aucun d’eux n’a eu à être instruit des autres : l’agent n’apprend jamais une API de déploiement, il ouvre une pull request ; Vercel n’apprend jamais rien de l’agent, il surveille le dépôt. La couture entre eux est le protocole git que tous trois parlent déjà, raison pour laquelle ajouter un agent à la chaîne n’a rien changé au fonctionnement du déploiement, et pour laquelle tout le chemin d’un prompt à la production ne comporte aucun passage de relais.

La conséquence est que le déploiement cesse d’être une étape que quelqu’un exécute et devient une conséquence de l’action git qu’il allait de toute façon accomplir. Un push est une compilation. Une pull request est un environnement de prévisualisation, créé et démantelé de lui-même. Une fusion dans la branche principale est un déploiement en production. Un revert est un retour arrière. Personne ne lance une mise en production ; on fusionne, et la mise en production se produit. Il n’y a pas de serveur de compilation à surveiller, pas de script de déploiement que l’agent pourrait rater, pas d’outil de promotion distinct, pas de fenêtre pendant laquelle quelqu’un a écrit le code mais ne l’a pas encore livré. Pour une équipe liée par la vérification, c’est exactement le bon endroit où supprimer la friction : le seul acte humain délibéré qui reste sur le chemin est la revue, qui est le seul acte qui devrait être délibéré, et tout ce qui est mécanique autour d’elle est pris en charge par les outils qui surveillent git.

C’est aussi pourquoi l’absence de couture est sûre plutôt que téméraire, et les deux propriétés découlent du même fait. Parce que le déploiement chevauche git, il hérite des garanties de git : chaque déploiement en production est lié à un commit revu précis, doté d’un auteur et d’un message ; chaque prévisualisation est liée à une branche ; et parce que les déploiements sont immuables, revenir en arrière consiste simplement à pointer la production vers la compilation d’un commit antérieur. Le même câblage qui laisse un changement circuler d’un prompt tapé sur un téléphone jusqu’à un site en service sans que quiconque touche une console de déploiement garantit aussi que rien n’atteint ce site en service autrement que par un commit revu, attribuable et réversible. L’intégration est une concordance non parce que les fournisseurs l’ont coordonnée mais parce que tous trois ont été bâtis pour traiter git comme la source de vérité, et lorsque l’agent a rejoint cette convention, le pipeline dont il avait besoin était déjà là.

8. Le terrain : Next.js

L’agent doit parcourir une base de code, et le framework de la base de code est le terrain. Next.js est un choix solide pour deux raisons qui reviennent toutes deux à la vérification. La première est qu’il est en TypeScript, et les types sont le premier garde-fou, le moins coûteux. Exécuté en mode strict, le vérificateur de types rejette une large classe d’erreurs — une forme erronée, un champ manquant, une valeur qui pourrait être nulle — au moment où l’agent l’écrit, c’est-à-dire exactement quand une correction est la moins coûteuse, avant que le code ne s’exécute et bien avant qu’un humain ne regarde. Nous poussons la même idée jusqu’aux confins du programme, en validant les entrées externes — corps de requêtes, variables d’environnement, lignes de base de données — face à un schéma, de sorte que les données non typées venues de l’extérieur deviennent typées et vérifiées à la frontière plutôt que d’être tenues pour acquises. Les types ne sont pas de la bureaucratie ici ; ils sont le garde-fou qui transforme l’erreur la plus courante de l’agent — une forme plausible subtilement erronée — en un soulignement rouge qu’il corrige lui-même.

La seconde raison est que Next.js est conventionnel, et son modèle, quoique riche, est assez balisé pour que l’agent l’écrive avec aisance. Il vaut la peine d’être concret au sujet de ce modèle, car c’est là que vit une grande part de l’ingénierie. L’App Router effectue le rendu sur le serveur par défaut : les Server Components s’exécutent sur le serveur et n’envoient jamais leur code au navigateur, gardant l’accès aux données et les secrets côté serveur, tandis que les Client Components, marqués explicitement, portent l’interactivité. Les mutations passent par les Server Actions, des fonctions serveur qu’un formulaire ou un bouton peut appeler directement, et les Route Handlers fournissent la surface d’API. Chaque route choisit comment elle effectue son rendu — statique au moment de la compilation, régénérée de façon incrémentale selon un calendrier, ou dynamiquement à chaque requête — et où elle s’exécute — le runtime Edge léger près de l’utilisateur ou le runtime Node.js plus complet —, avec un middleware qui s’exécute avant la requête pour prendre en charge des choses comme l’authentification et la langue. Cela fait beaucoup de leviers, mais ce sont des leviers publics, documentés et stables que l’agent a vus employés correctement à grande échelle, de sorte qu’il saisit le bon, et le framework est assez puissant pour construire un vrai produit tout en restant le terrain sur lequel l’agent est le plus capable, ce qui, par l’argument de la section 3, est la combinaison qui importe.

9. L’état : Postgres

Tout ce qui précède concerne le code, qu’il est sûr de modifier parce qu’il est versionné et réversible. Les données ne le sont pas : une colonne supprimée ou une mauvaise migration peut détruire quelque chose qu’aucun commit ne peut restaurer. Postgres est l’état durable et transactionnel au bas de la chaîne, et la discipline qui l’entoure est délibérément plus stricte qu’autour du code. PostgreSQL gagne sa place de la même manière que le reste de la chaîne : c’est le choix conventionnel, éprouvé au combat et superbement documenté, de sorte que l’agent écrit du SQL correct et des migrations correctes contre lui, et une instance infogérée supprime le labeur opérationnel sans changer le modèle.

Le soin porte sur le changement. Les changements de schéma sont des migrations : des fichiers ordonnés et versionnés enregistrés dans le dépôt et revus comme tout autre changement, exécutés contre la prévisualisation avant la production, et écrits pour être réversibles. Une base de données en production ne peut être modifiée comme une base neuve, de sorte qu’un changement risqué se fait comme une suite de changements sûrs, le motif expand and contract (Ambler & Sadalage, 2006) : ajouter la nouvelle colonne ou table et commencer à y écrire, remplir rétroactivement, faire basculer les lectures, et seulement alors, dans un déploiement ultérieur, retirer l’ancienne forme, de sorte qu’à chaque étape intermédiaire le code en fonctionnement et le schéma soient compatibles et que l’étape soit réversible. Postgres aide en rendant la plupart des changements de schéma transactionnels, de sorte qu’une migration en échec revient proprement en arrière plutôt que de laisser la base à demi modifiée. Deux points opérationnels importent dans un cadre serverless, où de nombreuses instances de fonction éphémères veulent chacune une connexion : un pooler de connexions n’est pas optionnel, parce qu’une base de données a une limite dure de connexions qu’une flotte de workers serverless épuiserait sinon ; et la sécurité au niveau des lignes laisse la base de données elle-même imposer qui peut voir quelles lignes, un filet de sécurité qui ne dépend pas de ce que l’application réussisse chaque requête. La règle que nous gardons est simple et mérite d’être énoncée : l’agent peut proposer une migration, mais une migration est le seul type de changement qu’un humain lit toujours avec toute son attention, parce que c’est le seul type que la chaîne ne peut pas défaire entièrement.

10. Le garde-fou humain et comment il défaille

Chaque garde-fou automatique de cette chaîne existe pour rendre le garde-fou humain peu coûteux, non pour le supprimer. Le relecteur à la pull request fait la seule chose qu’aucun garde-fou n’automatise : juger si le changement est ce que le métier voulait réellement et s’il est sûr de l’exposer, des questions que les types, les tests et les prévisualisations éclairent mais ne tranchent pas. Toute la finalité de la chaîne est de livrer à ce relecteur un changement petit, en fonctionnement et pré-vérifié, afin que le jugement soit rapide et bien fondé. Mais le garde-fou a des modes de défaillance caractéristiques, et les nommer fait partie du bon usage de la chaîne.

Le premier est l’approbation machinale. Lorsque l’agent a d’ordinaire raison, le relecteur apprend à approuver vite, et la revue dégénère en une formalité qui ne rattrape rien. La défense est de garder les changements petits, de sorte que les lire correctement reste peu coûteux, et de traiter la prévisualisation comme obligatoire, non optionnelle : une revue qui n’a pas parcouru le changement en fonctionnement n’est pas une revue. Le deuxième est l’excès de confiance, la croyance que, parce que le code a passé le vérificateur de types et les tests, il doit être correct ; ces garde-fous rattrapent les formes et les comportements mais non l’intention, et l’humain est le seul garde-fou sur l’intention. Le troisième est la fatigue d’échelle : un agent peut ouvrir plus de pull requests qu’une équipe ne peut en revoir sérieusement, et un arriéré de changements à demi revus est le régime lié par la vérification qui se réaffirme. La réponse n’est pas de revoir plus vite mais de générer plus délibérément, de laisser l’agent ne produire que ce que l’équipe peut réellement vérifier, parce qu’un changement non vérifié est un passif quel que soit son volume.

11. Coûts et arbitrages

La chaîne est un ensemble de choix, et l’honnêteté exige d’énoncer ce qu’ils coûtent. Le plus évident est le couplage : Next.js et Vercel viennent de la même entreprise, et bâtir sur eux achète un chemin fluide et intégré au prix d’un certain enfermement, à la fois dans un framework qui évolue vite et casse parfois la compatibilité entre versions majeures, et dans une plateforme d’hébergement dont on adopte la tarification et les primitives. Nous jugeons l’arbitrage valable pour la vélocité et la qualité de la boucle de prévisualisation, mais c’est une dépendance réelle, et une équipe devrait garder sa logique de domaine et ses données portables, de sorte que le framework et l’hébergeur restent une infrastructure remplaçable plutôt que le produit. Le deuxième coût est la discipline qu’exige le garde-fou : la chaîne n’est aussi sûre que la revue dans laquelle elle culmine, et une équipe qui laisse le garde-fou humain se dégrader en approbation machinale dispose d’un moyen rapide de livrer des erreurs assurées, ce qui est pire qu’un moyen lent de livrer des erreurs mûrement pesées. Le troisième est l’accès de l’agent : un outil qui peut modifier le dépôt et déclencher des déploiements est un acteur puissant, et il doit être cadré comme tel, avec la protection de branche, avec des identifiants au moindre privilège, avec des secrets tenus hors du dépôt et hors de portée de l’agent, et avec les changements de permissions et d’infrastructure revus avec un soin particulier. Le quatrième est l’irréversibilité des données, traitée plus haut : le seul endroit où le filet de sécurité de la chaîne a un trou, et l’endroit où dépenser le plus d’attention humaine. Aucun de ceux-ci n’est une raison de ne pas adopter la chaîne ; chacun est une raison de l’adopter délibérément.

12. Comment nous exploitons la plateforme Nashua 360 sur cette chaîne

La chaîne de cet article n’est pas une proposition que nous aurions théorisée ; c’est celle sur laquelle nous bâtissons et exploitons notre propre produit. La Nashua 360 Enterprise Platform est une application Next.js, déployée sur Vercel, adossée à Postgres, avec sa source sur GitHub, et elle est développée avec Claude Code comme agent, y compris depuis l’application mobile lorsqu’un changement est mieux lancé ou approuvé loin d’un bureau. Un fichier de conventions versionné indique à l’agent les règles de la maison ; chaque changement de la plateforme est une branche et une pull request ; chaque pull request obtient sa vérification de types, son exécution d’intégration continue et son déploiement de prévisualisation sur une copie isolée de la pile ; rien n’atteint la branche de production sans qu’un humain lise le diff et parcoure la prévisualisation ; et les migrations sont les changements que nous lisons le plus attentivement. Nous n’avons pas assemblé cette chaîne pour être à la mode. Nous l’avons assemblée parce que, une fois admis qu’un agent avait rendu la génération bon marché et la vérification la contrainte, chaque maillon découlait de la question de savoir comment vérifier vite et sûrement, et parce que le même raisonnement qui la rend juste pour nous — des outils conventionnels que l’agent manie bien, enveloppés de boucles et de garde-fous qui rattrapent ses erreurs — la rend juste pour la plupart des équipes qui construisent du logiciel web aujourd’hui. Qu’elle permette aussi de faire avancer un produit sérieux depuis un téléphone dans un train n’est pas la raison pour laquelle nous l’avons choisie, mais c’est un signe équitable de combien la forme du travail a changé.

13. Objections et réponses

Ce n’est que de la livraison continue avec un agent greffé dessus. En grande partie, délibérément. Les pratiques sur lesquelles repose la chaîne — gestion de versions, petits changements revus, intégration continue, déploiement automatisé avec prévisualisations et retour arrière — sont la discipline établie de la livraison logicielle moderne (Humble & Farley, 2010 ; Forsgren et al., 2018), et c’est bien là le point : l’agent ne remplace pas cette discipline, il en accroît la prime, parce que c’est la discipline qui fournit la vérification que la vitesse de l’agent exige désormais. La contribution n’est pas une nouvelle pratique mais l’argument des raisons pour lesquelles les anciennes pratiques importent davantage, non moins, une fois la génération bon marché.

Un meilleur modèle rendra l’outillage inutile. Il ne le fera pas, parce que l’outillage adresse la partie qu’un meilleur modèle ne touche pas. Un agent plus capable génère plus vite et, dans un monde lié par la vérification, générer plus vite n’élève pas ce qui part réellement en production ; seul vérifier plus vite le fait. Le meilleur modèle produit aussi plus de code, plus vite, qu’un humain doit vérifier, ce qui rend les garde-fous plus nécessaires, non moins. La chaîne est un pari sur la vérification, et ce pari s’améliore, loin de se détériorer, à mesure que la génération progresse.

Vous êtes enfermés dans la pile d’un seul fournisseur. En partie, et nous l’avons dit. Le couplage de Next.js et Vercel est un coût réel accepté pour un bénéfice réel, la boucle de prévisualisation intégrée qui est centrale à tout l’argument. L’atténuation est de garder portables la logique essentielle — le code de domaine et la base de données — et de traiter le framework et l’hébergeur comme une infrastructure remplaçable. Une équipe dotée d’un autre appétit pour le risque peut garder la forme de la chaîne — agent, gestion de versions, prévisualisation isolée, framework typé, base de données revue — sur d’autres composants.

14. Limites

Il s’agit de conseils destinés aux praticiens, et leurs limites doivent être énoncées. C’est une recommandation raisonnée ancrée dans notre propre usage, non une comparaison contrôlée ; nous n’avons pas mesuré la chaîne face à des solutions alternatives. Les outils précis sont à jour fin 2026, et c’est un domaine qui évolue vite : l’argument — que la vérification est la contrainte et que la chaîne doit se lire comme des boucles et des garde-fous — est censé survivre à tout outil particulier, mais les outils particuliers changeront, et un lecteur devrait garder l’argument et réexaminer les pièces. La recommandation est cadrée au genre de logiciel que nous construisons, des applications web dotées d’une base de données, et se transpose moins directement à des domaines aux contraintes différentes, tels que des systèmes où le coût d’un garde-fou de vérification est lui-même prohibitif, ou bien où aucun agent n’a vu assez de la pile pour qu’on puisse s’y fier. Et la sûreté de la chaîne repose sur un garde-fou humain que la chaîne rend peu coûteux mais ne peut rendre automatique ; une équipe peu disposée à maintenir ce garde-fou honnête devrait s’attendre à la vitesse sans la sûreté.

15. Conclusion

Un agent de codage rend l’écriture de logiciel rapide, et ce faisant met la partie difficile au grand jour. La génération, la partie qui dominait autrefois la journée, devient bon marché ; la vérification — décider quoi construire et être sûr que le résultat est juste — ne le devient pas, et devient la contrainte. La leçon pour l’outillage est que la valeur d’un dispositif assisté par IA n’est pas dans l’agent mais dans la chaîne qui l’entoure et qui permet à une équipe de vérifier à la vitesse à laquelle l’agent génère et de rattraper ses erreurs avant les utilisateurs. Nous bâtissons et exploitons la plateforme Nashua 360 sur une telle chaîne : Claude Code pour écrire, en boucle avec les vérifications et accessible depuis un téléphone ; GitHub pour faire de chaque changement un diff revu et réversible derrière une branche protégée ; Vercel pour donner à chaque changement sa propre prévisualisation active et à chaque mise en production un retour arrière instantané ; Next.js comme terrain typé et conventionnel dont les types sont le premier garde-fou ; et Postgres comme état durable modifié par des migrations revues et réversibles. Chaque maillon referme une boucle ou ajoute un garde-fou, les garde-fous sont indépendants de sorte qu’aucun d’eux ne doit être parfait, et l’ensemble est choisi sur un critère propre à ce moment : que pour un agent, l’outil conventionnel est l’outil capable. Écrire vite, vérifier plus vite, et ne laisser rien atteindre la production qu’une personne n’a pas vu fonctionner. C’est tout, et cela suffit.

Annexe A. Une liste de contrôle d’adoption

Les pratiques ci-dessous sont ce qui rend la chaîne sûre plutôt que simplement rapide. Aucune n’est nouvelle ; la discipline est la valeur.

Références

Ambler, S. W., & Sadalage, P. J. (2006). Refactoring databases: Evolutionary database design. Addison-Wesley. ISBN 978-0-321-29353-5.

Bacchelli, A., & Bird, C. (2013). Expectations, outcomes, and challenges of modern code review. In Proceedings of the 35th International Conference on Software Engineering (ICSE) (pp. 712–721). IEEE. https://doi.org/10.1109/ICSE.2013.6606617

Beck, K. (2000). Extreme programming explained: Embrace change. Addison-Wesley. ISBN 978-0-201-61641-5.

Brooks, F. P. (1987). No silver bullet: Essence and accidents of software engineering. Computer, 20(4), 10–19. https://doi.org/10.1109/MC.1987.1663532

Chen, M., Tworek, J., Jun, H., et al. (2021). Evaluating large language models trained on code. arXiv preprint arXiv:2107.03374. https://arxiv.org/abs/2107.03374

Anthropic (2026). Claude Code documentation. https://code.claude.com/docs

Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The science of lean software and DevOps: Building and scaling high performing technology organizations. IT Revolution Press. ISBN 978-1-942788-33-1.

Fowler, M. (2006). Continuous integration. martinfowler.com. https://martinfowler.com/articles/continuousIntegration.html

GitHub (2026). GitHub documentation. https://docs.github.com

Humble, J., & Farley, D. (2010). Continuous delivery: Reliable software releases through build, test, and deployment automation. Addison-Wesley. ISBN 978-0-321-60191-9.

Vercel (2026). Next.js documentation. https://nextjs.org/docs

Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). The impact of AI on developer productivity: Evidence from GitHub Copilot. arXiv preprint arXiv:2302.06590. https://arxiv.org/abs/2302.06590

PostgreSQL Global Development Group (2026). PostgreSQL documentation. https://www.postgresql.org/docs/

Reason, J. (2000). Human error: Models and management. BMJ, 320(7237), 768–770. https://doi.org/10.1136/bmj.320.7237.768

Sadowski, C., Söderberg, E., Church, L., Sipko, M., & Bacchelli, A. (2018). Modern code review: A case study at Google. In Proceedings of the 40th International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP) (pp. 181–190). ACM. https://doi.org/10.1145/3183519.3183525

Vercel (2026). Vercel documentation. https://vercel.com/docs