Build vs tests : pourquoi « ça passe » ne veut pas dire « ça marche »

Mik Bry · 2026-08-25 · lecture ~7 min · Launch Readiness · Tests

Le build de ton app passe. Ton agent IA te dit que c'est fait. C'est pareil que « ça marche », non ?

Pas tout à fait, et c'est souvent là que les problèmes passent inaperçus dans une app construite avec l'IA. Un build qui passe te dit quelque chose de réel — juste pas ce que la plupart des gens croient.

Cet article parle de cet écart : ce qu'un build vérifie vraiment, ce qu'un test vérifie vraiment, et pourquoi la différence compte davantage quand c'est ton agent qui t'annonce « ça passe ».

01 — Ce que « build » et « tests » veulent vraiment dire

Un « build » est l'étape qui transforme ton code source en quelque chose capable de tourner. Selon la configuration du projet, cette étape peut vérifier que le code compile, que les types sont cohérents, que le formatage respecte les règles, que les images et autres fichiers sont bien générés — et parfois, selon la configuration, elle fait tourner un lot de tests aussi. Ce qui compte exactement comme « le build » est une décision propre à chaque projet, pas une liste universelle figée.

Les « tests » sont un type de vérification différent. Ils ne demandent pas si le code est assemblé correctement — ils demandent si le comportement est correct. Est-ce que l'écran de connexion laisse vraiment entrer la bonne personne et pas une autre ? Est-ce que le paiement est bien enregistré quand la carte est débitée ? Est-ce que les données d'un client restent vraiment invisibles pour un autre ?

Imagine un texte sans aucune faute de grammaire : chaque mot est correct, chaque phrase est bien construite, mais l'ensemble ne veut rien dire.

Le build vérifie en quelque sorte la grammaire. Les tests vérifient le sens : est-ce que le logiciel fait réellement ce que tu attends de lui ?

Le build répond à : est-ce que ce logiciel peut être assemblé, tout simplement ? Les tests répondent à : est-ce que le comportement qui compte vraiment fonctionne encore ? Les deux vérifications sont utiles. Aucune ne remplace l'autre.

02 — Pourquoi un build vert ne prouve pas que le produit fonctionne

« Le build est passé » est une affirmation plus étroite qu'elle n'en a l'air. Ça veut dire que les vérifications incluses dans cette configuration de build sont passées — rien de plus. Un build vert ne prouve pas que la connexion fonctionne. Il ne prouve pas qu'un paiement est bien enregistré. Il ne prouve pas qu'un client ne peut pas voir les données d'un autre client. Il dit simplement que les vérifications configurées n'ont pas échoué. Si rien n'a vérifié le paiement, le build n'a rien à dire sur le paiement — vert ou pas.

L'image de la grammaire tient toujours : une phrase avec une orthographe et une grammaire parfaites peut quand même dire quelque chose de complètement faux, ou ne rien dire du tout. Le build vérifie la grammaire, pas le sens.

Cet écart devient plus net quand c'est un agent IA qui écrit et déploie le code. Un message de succès — humain ou IA — n'est pas une preuve. Avec l'IA, le volume et l'assurance de ces messages rendent cette nuance particulièrement facile à oublier : « build réussi », « c'est fait », « ça devrait marcher maintenant », annoncés sur le même ton rassurant, que quelqu'un ait réellement vérifié la chose qui compte pour ton activité ou non. Ton seul signal d'alerte devient le silence : aucune erreur, aucun avertissement, rien de visible qui cloche — jusqu'à ce qu'un client payant clique sur un bouton de paiement qui, discrètement, n'enregistre rien.

Sources : Le TestPyramid de Martin Fowler distingue un *build automatisé* — qui compile et empaquette le logiciel automatiquement — d'un *build auto-testant*, dont les tests automatisés donnent une vraie confiance dans le comportement du logiciel. Le principe voisin de Kent C. Dodds, cité par web.dev, vaut la peine d'être gardé en tête dans toute conversation avec ton agent IA sur les tests (traduction) : « Plus tes tests ressemblent à la façon dont ton logiciel est réellement utilisé, plus ils peuvent t'inspirer confiance. »

03 — À quoi ressemble une bonne couverture de tests

Tu n'as pas besoin d'une couverture de tests exhaustive avant de lancer. Tu as surtout besoin de tests sur les quelques flux qui te feraient vraiment mal s'ils cassaient en silence. Pour la plupart des apps construites par un fondateur, ce sont quatre flux :

• La connexion — la bonne personne entre, la mauvaise n'entre pas.
• Les paiements — un paiement est bien enregistré, et un paiement refusé ou qui échoue ne débloque pas quand même l'accès en silence.
• Les changements de données — le changement qui a lieu en production est bien celui que tu voulais, et il ne fuite pas vers le compte d'un autre client.
• La récupération de compte — un utilisateur bloqué peut revenir par un chemin qu'un attaquant ne peut pas emprunter aussi facilement.

Si des tests sérieux existent pour ces flux, tu pars d'une bien meilleure base, même si le reste de l'app est peu couvert. S'il n'en existe aucun pour ces quatre flux, le fait que le build passe te dit très peu de choses sur le fait que l'app soit prête à accueillir des clients payants.

La valeur des tests dépend aussi de la fréquence à laquelle ils sont réellement exécutés. Une suite de tests qui existe mais qu'on ne lance qu'à la main, de temps en temps, quand quelqu'un y pense, te protège bien moins qu'une suite relancée automatiquement à chaque changement de code — ce qu'on appelle généralement l'intégration continue. Les tests posent les questions ; la relance automatique s'assure que ces questions sont posées à chaque fois, pas seulement la première.

04 — Ce que tu peux demander sans risque à ton agent IA

Tu n'as pas besoin d'écrire des tests toi-même, et tu n'as pas non plus besoin de demander à ton agent d'en écrire maintenant. Le premier geste utile, c'est juste de savoir ce qui existe déjà — et d'être précis sur ce que veut vraiment dire « je n'ai rien trouvé ». Si ton agent ne trouve pas de test pour quelque chose, ça veut dire que la recherche n'a rien donné, pas que le test est garanti de ne pas exister quelque part qu'il n'a pas regardé. Demande-lui d'être honnête sur cette nuance.

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.