Ton IA vient de dire « c'est fait ». Qu'est-ce qui a vraiment vérifié ça ?
Ton outil d'IA dit « c'est fait ». Il a corrigé le bug, ajouté le champ, poussé le changement — fait. Mais « c'est fait » ne dit pas ce qui a réellement été vérifié.
« C'est fait » veut généralement dire que l'agent pense que le changement correspond à ce que tu as demandé. Ça ne veut pas dire qu'un mécanisme séparé a relancé les vérifications du projet.
Avec l'historique de versions, c'est l'une des premières choses que je regarde quand j'examine une app construite avec l'IA : est-ce qu'il existe un mécanisme qui relance les vérifications connues sur les changements concernés, automatiquement, que l'agent pense à le mentionner ou non. Pas parce que ton agent te ment. Parce que « c'est fait » est une affirmation faite dans une conversation, et une affirmation n'est pas la même chose qu'une vérification relancée.
01 — C'est quoi, concrètement ?
CI veut dire Continuous Integration — intégration continue. Le nom n'aide pas beaucoup, alors laisse-le de côté et retiens plutôt le mécanisme : la CI est un processus séparé et répétable qui exécute automatiquement des vérifications configurées quand du code pertinent est poussé ou proposé en pull request. Ces vérifications peuvent inclure la construction (le build), le typage, le linting et les tests. Elle répète tout ce que tu as configuré — en général sur un serveur, pas sur la machine de ton agent. Martin Fowler, qui écrit là-dessus depuis les années 1990, résume l'essentiel simplement : une construction automatisée, « tests compris », qui vérifie chaque changement pour « détecter les erreurs d'intégration le plus vite possible ».
Voici la précision que je veux poser avant d'aller plus loin, parce que beaucoup d'explications passent ce point sous silence : la CI n'est pas un relecteur indépendant qui surveille ton agent par-dessus son épaule. Le même agent qui a écrit le code a très bien pu écrire les tests que la CI fait tourner, et la configuration qui lui dit quoi vérifier. La CI n'ajoute pas un second avis. Ce qu'elle apporte est plus limité, mais très utile : la répétabilité. Les mêmes vérifications connues, relancées de la même façon, sur les changements concernés, que quelqu'un — humain ou agent — pense à les relancer à la main ou non.
Pense à un pilote qui a dix mille heures de vol et qui refait quand même la checklist avant chaque décollage. Pas parce qu'il doute de son propre jugement — parce qu'une checklist qu'on ne lit que de temps en temps n'est plus une checklist, c'est une suggestion. La CI, c'est la partie du processus qui ne saute jamais la checklist, parce qu'elle ne peut ni être débordée, ni oublier, ni décider « ce changement est petit, ça ira ».
Et le rôle de la CI s'arrête là, volontairement. Fowler insiste aussi sur ce point : décider de vraiment publier ce que la CI a vérifié reste, selon ses mots, « une décision business » — une étape séparée, prise par des humains, informée par ce que la CI a trouvé. La CI ne décide pas de mettre en ligne. Elle s'assure juste que celui qui décide le fait avec les vérifications vraiment relancées, pas juste un « c'est fait » dit en passant.
02 — Pourquoi s'en soucier si tu ne codes pas ?
Parce que ton agent peut dire « c'est fait », le penser sincèrement, et se tromper quand même — et sans CI, la première fois que quelqu'un relance vraiment les vérifications, ce sera peut-être au moment où la carte d'un client se fait refuser, pas avant que tu ne mettes en ligne.
Build vs tests, un autre article de cette série, parle de l'écart entre un build qui compile et un produit qui marche vraiment : un build vert prouve seulement que les vérifications incluses dans ce build sont passées, rien de plus. C'est là que la CI devient utile : elle relance automatiquement ces vérifications, sur les changements concernés, au lieu de dépendre de quelqu'un qui pense à les lancer manuellement.
Sans CI, vérifier devient un événement rare et redouté : quelque chose qui arrive seulement juste avant une grosse mise en production, sous pression, au moment où tout le monde est le moins équipé pour gérer ce que ça révèle. Avec elle, la vérification devient une routine banale : elle tourne discrètement, toujours de la même façon. Ce basculement, d'occasionnel et stressant à routinier et banal, c'est à peu près ce que la CI t'apporte réellement.
03 — À quoi ressemble un projet bien structuré ?
Pas besoin de lire une ligne de configuration pour vérifier l'essentiel. Cherche :
- Ça tourne automatiquement sur les changements concernés — par exemple quand du code est poussé ou qu'une pull request est ouverte.
- Ça relance des vérifications qui existent déjà — le build, les tests déjà écrits pour ce projet. La CI n'invente pas de nouveau jugement ; elle vaut ce qu'on lui a dit de vérifier.
- Le résultat est visible sans lire de code — une coche verte ou une croix rouge à côté de chaque changement, le genre de statut que GitHub Actions affiche sur chaque pull request.
- Ça tourne ailleurs que sur l'ordinateur d'une seule personne — pour que « ça marche chez moi » ne soit pas le dernier mot sur si ça marche vraiment.
- Quand une vérification échoue, quelqu'un est réellement prévenu — pas un statut rouge que personne ne regarde.
Si ton projet n'a rien de tout ça, ce n'est pas automatiquement une crise — un tout jeune prototype n'en a peut-être pas encore besoin. Mais dès que de vrais utilisateurs entrent en jeu, c'est la différence entre trouver un changement cassé en quelques minutes, ou le découvrir par un email de support.
Référence : l'aperçu de la CI/CD par Red Hat est une bonne suite de lecture si tu veux la vue d'ensemble au-delà de ce qu'un seul article peut couvrir.
04 — Que peux-tu demander sans risque à ton agent IA ?
Tu n'as besoin de trouver aucun de ces points toi-même. Demande à ton outil d'IA de te montrer — et la formulation exacte compte, parce que « je n'ai rien trouvé » n'affirme pas la même chose que « il n'y a rien ». Si ton agent ne trouve pas de CI, la réponse honnête est qu'il n'en a pas trouvé, pas qu'il n'en existe pas. Copie-colle ce prompt tel quel :
Liste toutes les vérifications qui tournent automatiquement avant que cette app soit déployée — builds, tests, tout ce qui existe — et où chacune est configurée. Si tu n'en trouves aucune, dis-moi que tu n'en as pas trouvé — ne suppose pas qu'il n'y en a pas. Ne rajoute et ne change rien.
Lis la réponse avant d'agir dessus. Si ton agent liste un vrai pipeline automatisé qui relance builds et tests sur les changements concernés, c'est exactement ce que décrit la section 3 pour un projet bien structuré, confirmé. S'il revient bredouille, ça ne prouve pas que rien n'existe — mais c'est un vrai point de départ, et ça vaut la peine de le comprendre avant que le prochain changement soit mis en production.
Cet article fait partie de la série Launch Readiness KB : un concept à la fois pour comprendre ce que le Trust Report vérifie avant de lancer ton app, d'embaucher ou de lever des fonds. Chaque article se termine par quelque chose que tu peux demander à ton agent sans modifier le code.