Livré ne veut pas dire fiable : comment je vérifie ce que je construis pour vous

Un prestataire vous dit « c'est fait ». Comment savez-vous que ça marche vraiment — pas seulement dans la démo qu'on vous a montrée, mais dans les cas que personne n'a pensé à tester : deux actions simultanées, une connexion qui coupe au mauvais moment, un écran qui se rafraîchit une seconde trop tôt ?

La plupart du temps, vous ne le savez pas. Vous faites confiance, et vous découvrez les problèmes quand vos propres utilisateurs les découvrent. Voici comment j'évite ça.

Le vrai problème : « terminé » et « fiable » sont deux choses différentes

Une fonctionnalité peut sembler terminée — l'écran s'affiche, le bouton fait quelque chose — sans être fiable dans les situations réelles. Le décalage se loge presque toujours dans ce qu'on n'a pas pensé à vérifier : que se passe-t-il si deux personnes agissent au même instant ? Si la page se recharge avant que le message d'erreur ait été lu ? Si une donnée censée être protégée se retrouve quand même visible ?

Ce sont exactement les cas qu'un simple coup d'œil sur l'écran ne révèle jamais.

La méthode Foyer, en une idée

Le principe central est simple à énoncer, et pourtant rarement appliqué avec discipline : jamais mon seul jugement, jamais celui de l'IA qui m'assiste — toujours un outil externe qui vérifie le résultat, à chaque étape.

Concrètement, chaque étape de travail suit le même cycle : on conçoit, on construit, on regarde le résultat, un outil objective si ça fonctionne réellement — pas une impression, une vérification mécanique — et on améliore avant de reprendre. C'est ce quatrième temps qui change tout : il retire la question « est-ce que ça marche ? » des mains de qui vient de le construire.

Avant toute décision qui vous engage, je me pose une question simple : pourrai-je en répondre, devant vous, si ça tourne mal ? Cette question est le vrai garde-fou. Le risque qu'elle surveille n'est pas l'incompétence — c'est l'usure de la vigilance : devenir, avec le temps, assez confiant pour arrêter de vérifier. La méthode existe justement pour que la vérification reste un réflexe mécanique, pas une bonne intention qui s'érode.

La preuve plutôt que la confiance sur parole

Un rapport qui dit « tout est vert » ne prouve pas grand-chose si personne ne peut le relire de façon indépendante. Sur un projet récent, j'ai poussé cette logique jusqu'au bout : les parcours utilisateurs les plus sensibles sont filmés, à vitesse humaine, contre le vrai système — pas simulés, pas accélérés pour que ce soit illisible.

Le parcours le plus révélateur est filmé avec deux écrans côte à côte, parce que ce qui prouve la fiabilité n'est pas ce que fait une personne, mais ce que voit l'autre pendant qu'elle agit : est-ce qu'une information sensible reste bien invisible tant qu'elle ne doit pas l'être ? Est-ce que chacun est informé de ce qui vient de se passer, sans avoir à rafraîchir la page lui-même ?

Détail qui compte autant que le reste : quand un parcours n'est pas encore filmé, je le dis explicitement, plutôt que de laisser croire qu'il n'a jamais existé. Une preuve incomplète mais honnête vaut mieux qu'une preuve qui cache ses trous.

Un vrai défaut trouvé, pas un exemple théorique

Voici ce que ce processus a concrètement attrapé sur un projet récent, avant qu'aucun utilisateur ne le voie : après qu'une mise en relation avait échoué au profit d'une autre personne, un message expliquant ce qui s'était passé s'affichait bien — puis un rafraîchissement automatique de l'écran l'effaçait avant que quiconque ait eu le temps de le lire. La personne concernée se serait retrouvée sans aucune explication.

Ce n'est pas le genre de défaut qu'on repère en relisant le code ou en cliquant une fois sur un bouton. C'est le genre de défaut qu'on ne voit qu'en rejouant le scénario complet, en le regardant vraiment se dérouler. C'est exactement ce que la vérification systématique est censée attraper — et c'est exactement ce qu'elle a fait ici.

Ce que je vous dis aussi quand ça ne marche pas encore

La méthode ne prétend pas à la perfection : elle demande d'être honnête sur ses limites, pas de les cacher. Sur ce même projet, une donnée qui n'aurait jamais dû se retrouver dans un document destiné à être rendu public s'y était glissée. Je l'ai repérée, corrigée — et surtout, j'en ai fait un contrôle automatique qui bloque désormais toute publication contenant ce type de donnée. Ce contrôle a immédiatement retrouvé un second cas que personne n'avait vu.

C'est la réponse que la méthode impose face à une erreur : pas seulement la corriger, mais transformer la vigilance qui l'a repérée en barrière qui ne dépend plus de la mémoire de quelqu'un.

Pourquoi ça compte pour vous

• Vous n'avez pas besoin de savoir lire du code pour être rassuré : la preuve est filmée, pas seulement affirmée.
• Les défauts invisibles au premier coup d'œil sont ceux que la méthode cible en priorité — c'est précisément là que se cachent les mauvaises surprises en production.
• L'honnêteté sur les limites fait partie du livrable, pas seulement le résultat qui fonctionne.
• Le jugement humain reste là où il compte — aux décisions qui vous engagent — pendant que la vérification, elle, tourne en continu et sans relâche.

C'est cette méthode, avec la même rigueur, que j'applique à chaque mission — contactez-moi si vous voulez qu'on en discute pour votre projet.