Jidoka Lab

Comment j'en suis arrivé là

Parcours et méthode

De testeur d'applications à constructeur d'outils qui tournent seuls, sans jamais lâcher la règle de départ : chercher ce qui casse avant que ça casse.

Le testeur

J’ai commencé en 2016 par le support et l’intégration : des postes à migrer, des applications métier à faire tenir, des anomalies à qualifier et à faire remonter. Puis le test logiciel est devenu mon métier, en freelance dès 2019.

Une plateforme de mise en relation entre freelances et clients, où j’ai écrit les critères d’acceptation avec les product owners et posé l’automatisation (Cypress, Gherkin). Un promoteur immobilier, où j’ai construit une stratégie QA à partir de rien pour deux applications de gestion commerciale : cahier de tests, non-régression, tests d’API, automatisation, ateliers de recette avec le métier. Le commerce en ligne d’une grande enseigne, où j’étais référent QA d’une équipe : tests d’API, insertion de jeux de données en MongoDB et Elasticsearch, monitoring sur Kibana et Kubernetes, lecture de logs, jobs d’import et d’export, recette web et mobile, comités de mise en production. Et depuis 2022, une montre connectée de luxe : applications mobile et montre, capteurs, synchronisation, tout ce qui se casse loin des yeux.

Ce métier apprend une chose que les constructeurs oublient : un système ne vaut que par ce qu’il fait quand tout ne va pas.

Le déclic

En 2026, les outils d’IA ont changé ce qu’une personne seule peut construire. Beaucoup ont vu la vitesse. J’ai vu le risque : du code produit en minutes, jamais éprouvé, mis en production par des gens qui n’ont jamais eu à répondre d’un bug à 3 h du matin.

Alors j’ai fait l’inverse. Construire vite, oui, mais avec la discipline du testeur : chaque outil que je fabrique passe par les mêmes fourches que les produits que j’ai testés pour d’autres. Un essai à blanc avant la première vraie fois. Un journal. Un garde-fou humain avant tout geste irréversible. Une documentation qu’un agent peut lire pour prendre le relais.

Résultat : un portfolio qui rassemble des systèmes utilisés au quotidien, des tests privés, des prototypes et des spécifications volontairement non codées. Leur point commun : une limite explicite, un chemin d’échec prévu et une validation humaine aux gestes qui comptent. Les deux plus critiques comptent 350 tests automatisés ; pour les autres, chaque fiche dit ce qui est démontré et ce qui ne l’est pas.

Les règles

Le problème avant la solution. Quel est le vrai problème, pour qui, et existe-t-il une façon de le régler sans code ? Un de mes projets est resté à l’état de spécification parce que la réponse n’était pas assez claire. C’est aussi une décision.

Le minimum qui tient. Pas d’abstraction pour du code à usage unique, pas de dépendance dont je n’ai pas pesé le coût de maintenance, pas d’abonnement quand une solution déterministe et gratuite existe.

La machine s’arrête, l’humain tranche. Rien d’irréversible ne part sans un geste explicite. Quand un service tiers n’offrait pas d’étape de validation, je l’ai construite dans mon code plutôt que de faire confiance.

Prévoir l’échec, pas seulement le succès. Une donnée manquante est un cas normal. Un document envoyé trop tôt, une signature qui n’arrive pas, une erreur découverte après coup : chaque cas a son chemin dessiné avant l’écran.

Exploitable sans moi. Les systèmes qui tournent en continu ont une fiche d’exploitation, lisible par un humain comme par un agent. Un agent de supervision tourne en continu sur cette base et me prévient avant que je ne remarque une panne.

Comment je travaille avec les agents

Les agents diagnostiquent, extraient, structurent, testent et documentent. Je garde le problème, les critères d’acceptation et les décisions. Toute sortie vers l’extérieur ou tout geste irréversible attend ma validation. Et les résultats qui comptent sont relus dans le système réel, pas dans la conversation.

Ce que je sais faire

Tester. Stratégie de test posée à partir de rien ou reprise en cours de route ; cas de test, critères d’acceptation, non-régression ; tests d’API (Postman, scripts automatisés en intégration continue) ; automatisation web (Cypress) ; tests de données et de back-end (MongoDB, Elasticsearch, jeux de données, jobs) ; monitoring et lecture de logs (Kibana, Kubernetes) ; recette web sur tous navigateurs et mobile iOS et Android ; comités de mise en production ; référent d’une équipe de testeurs ; outillage Jira, Squash, Xray, Azure DevOps, Confluence.

Construire. Python et FastAPI, bases de données légères, interfaces conversationnelles, PWA mobile, vision par ordinateur, transcription et voix, agents IA et orchestration, montage vidéo piloté par script (DaVinci Resolve), hébergement maison sur réseau privé, déploiement et supervision.

Avec l’IA. Je travaille avec plusieurs assistants de code (Claude Code, Codex) et plusieurs familles de modèles selon la tâche : modèles distants (Claude, Gemini, DeepSeek) quand la qualité prime, modèles locaux quand la confidentialité prime, Midjourney pour l’image, Suno pour la musique, Higgsfield puis Seedance pour l’animation. Le choix de l’outil fait partie du travail, et il se remesure : l’animation a changé de fournisseur sur une comparaison chiffrée.