Vérifier ce qu'il rend5 minFondation

Prouvé, ou simplement pas encore réfuté

Prouvé signifie qu'une commande précise a tourné et que sa sortie a été lue ; pas encore réfuté signifie seulement que rien n'a attrapé de problème jusqu'ici, une affirmation bien plus faible.

Une vérification de types prouve qu'aucune incohérence de type n'a été détectée dans les fichiers examinés, pas que le code compile ni qu'il s'exécute : la résolution des modules, l'empaquetage et les dépendances natives restent hors de son périmètre. Une suite de tests prouve que les chemins qu'elle exerce se comportent comme écrit. Un aperçu sans interface, une exécution simulée sans qu'aucun humain touche un vrai écran, prouve que les composants se montent sans planter. Rien de tout cela ne prouve qu'un produit fonctionne vraiment pour une personne qui tient un vrai appareil.

Deux mots qu'on confond sous une seule étiquette

La plupart des cours sur les tests mélangent deux états très différents sous le mot testé. La distinction honnête sépare deux affirmations. Prouvé signifie que vous avez exécuté une commande précise et que vous pouvez citer sa sortie. Pas encore réfuté signifie que rien n'a attrapé de problème jusqu'à présent, ce qui est une affirmation bien plus faible : un aperçu vert ou une absence d'erreur en console signifie seulement que les vérifications menées n'ont pas révélé de défaut par hasard, pas qu'aucun défaut n'existe.

Un format qui semble correct illustre bien l'écart. Une expression régulière de numéro de téléphone peut être exécutée et sa sortie citée : c'est prouvé, au sens strict.

$ node -e "console.log(/^\+33[1-9][0-9]{8}$/.test('+33199999999'))"
true

Ce que cette ligne prouve s'arrête là : la chaîne a la forme attendue. Elle ne prouve rien sur le numéro lui même, qui reste seulement pas encore réfuté tant que personne n'a composé la ligne pour de vrai.

Des signaux au vert, et pourtant des défauts

Voir la figure : des lots ont été livrés avec tous les signaux automatisés au vert, vérifications de types réussies, couverture complète, aperçu sans interface propre. La personne qui a réellement installé l'application sur un vrai appareil a trouvé des problèmes en quelques minutes, dont aucun n'avait été attrapé par un contrôle : une lenteur qui n'apparaît que sous un vrai écran tactile et une vraie pression mémoire, un paramètre réglé pour le mauvais matériel, et un bouton de contact qui composait une ligne fixe qu'une application de messagerie ordinaire ne pourrait pas atteindre. Chacun de ces défauts était invisible par construction pour une exécution sans interface, qui n'a ni doigt, ni écran, ni ligne téléphonique.

Le correctif est dans le rapport, pas dans plus d'automatisation

Ajouter des vérifications automatisées ne répare pas cette classe de défaut, qui résiste à l'automatisation par nature. Le correctif est l'honnêteté du rapport de statut, un thème déjà posé à propos de ce qu'une vérification très rigoureuse ne peut pas voir. Avant de déclarer un travail terminé, écrivez ce qui a été prouvé, avec la commande et la ligne de sortie citée, et ce qui reste seulement pas encore réfuté, comme un aperçu propre ou une console silencieuse. Nommez d'avance ce qui ne peut être tranché que sur un vrai appareil ou par un vrai utilisateur, pour que personne ne confonde ce silence avec un verdict.

Figure 1

Ce que chaque contrôle prouve, et ce qu'il ne peut pas prouver

Vérification automatisée	Ce qu'elle prouve vraiment	Ce qu'elle ne peut pas prouver
La vérification de types réussit	Aucune incohérence de type détectée entre les fichiers résolus	La syntaxe des fichiers hors du périmètre typé, l'exécution réelle, le comportement sur un vrai appareil
Le lint réussit	Le code respecte les règles de style et les motifs dangereux que le linter connaît	L'absence d'erreur de type, le comportement réel sur un vrai appareil
Aperçu sans interface, zéro erreur console	Les composants se montent sans planter	L'écran est lisible sous un vrai doigt, l'animation semble fluide
La suite de tests complète est verte	Les chemins codés se comportent comme écrit	La fonctionnalité fait ce dont l'utilisateur avait vraiment besoin
Un champ numéro de téléphone correspond au format attendu	La chaîne a la bonne forme	Le numéro atteint une ligne active sur ce canal réel

Cinq contrôles différents, chacun avec sa propre limite, listés côte à côte plutôt que fondus en une seule ligne qui masquerait leurs garanties distinctes.

Figure 2

Signaux au vert, défauts trouvés seulement à l'usage réel

7lots livrés

Lots livrés avec vérification de types, couverture de tests et aperçu sans interface tous au vert, où un usage réel sur un vrai appareil a quand même trouvé des défauts

p20l13, 2026

Un chiffre daté et sourcé isole ce fait en un seul endroit, pour qu'il ne se périme qu'une fois si le lot cité change de nature.

Calibrez vous-même

Un écran d'application est rendu par un outil d'aperçu automatisé qui s'exécute sur le serveur d'intégration continue. Cet aperçu s'appuie sur un moteur de rendu qui simule la structure des composants directement en mémoire, sur ce même serveur. Le rendu se termine, la console n'affichant aucune erreur.

Écrivez en une phrase ce que ce résultat établit, et en une phrase ce qu'il n'établit pas.

Votre réponse, avant de voir le corrigé

Ce qu’il faut retenir

Prouvé désigne une commande précise qui a tourné et dont la sortie a été citée ; pas encore réfuté désigne seulement l'absence de problème constatée jusqu'ici, une affirmation nettement plus faible.
Un aperçu sans interface prouve que les composants se montent sans planter, jamais qu'un écran reste lisible sous un doigt réel ou qu'un numéro de téléphone est joignable.
Plusieurs lots livrés entièrement au vert ont quand même échoué à l'installation réelle, voir la figure, sur une lenteur, un mauvais paramètre matériel et un bouton composant une ligne injoignable.
Avant de livrer, séparez par écrit ce qui est prouvé de ce qui est seulement pas encore réfuté, et nommez ce que seul un vrai appareil peut trancher.

À faire maintenant

Reprenez la dernière affirmation de succès que vous avez faite sur votre propre travail et séparez la en deux listes : ce qui est prouvé, avec la commande exacte et la ligne de sortie citée, et ce qui reste seulement pas encore réfuté, comme une absence d'erreur constatée.