Edge Case

Contexte

Le projet est né d'une frustration banale pour un PM : écrire une spec sans savoir ce que le code existant va en faire. On décrit un comportement attendu, on le livre à l'équipe, et c'est seulement à ce moment que les questions surgissent. "Ce cas-là, t'en as pas parlé." "Cette règle contredit ce qu'on a mis en place le trimestre dernier." Les edge cases émergent en sprint, parfois en production, jamais au stade où les corriger ne coûte rien.

Problème

Le problème n'est pas la qualité de l'écriture des specs. La plupart des PMs savent structurer une spec. Le problème est que cette spec est écrite sans connaissance du code sur lequel elle va s'appliquer. La codebase est un territoire que les équipes produit traversent rarement en première main : des décisions prises sans voir les contraintes existantes, des conflits découverts en développement, des cas limites intégrés en urgence ou ignorés.

Un développeur expérimenté peut faire cette analyse à la main. Mais ça prend du temps, ça suppose une disponibilité qu'on n'a pas toujours, et ça reste informel. Il n'y a pas de moment structuré où quelqu'un confronte systématiquement une nouvelle spec au code existant.

Démarche

J'ai codé l'outil moi-même, avec une assistance IA. Je ne suis pas développeur, et c'est justement le point : les outils disponibles aujourd'hui permettent à un PM de construire un produit fonctionnel et de le mettre en production. Ça change ce qu'on peut proposer.

Ce faisant, je me suis retrouvé dans la codebase, et ça a validé la thèse du produit par l'expérience. Les contraintes du code deviennent concrètes quand on les touche.

Pour les analyseurs IA, j'ai décomposé l'analyse en trois questions : est-ce que la spec contredit quelque chose dans le code ? Quels scénarios n'ont pas été prévus ? Quels fichiers sont affectés ? Chaque question est traitée séparément, ce qui permet des résultats ciblés plutôt qu'un rapport généraliste.

Ce que j'ai fait

Le flux principal est simple : l'utilisateur sélectionne un repo GitHub, colle une spec, lance l'analyse. Trois sections de résultats s'affichent : conflits, edge cases oubliés, fichiers impactés par priorité. Un rapport exportable.

Le choix de laisser les utilisateurs apporter leur propre clé API OpenAI ou Anthropic était une décision de confiance : les équipes analysent leur code source, elles doivent savoir où leurs données vont.

Résultats & impact

Le MVP est en production sur edge-case.app. Les métriques d'usage externe sont trop limitées pour en tirer des conclusions. Quelques utilisateurs en accès beta, des retours qualitatifs positifs. Sur mes propres specs, l'outil a identifié plusieurs contradictions que je n'avais pas vues.

Recul

Le vibe coding est une démarche puissante mais qui accumule de la dette technique sans toujours le voir. J'ai fait des choix d'architecture que j'aurais faits différemment avec plus d'expérience. Cela renforce, paradoxalement, la thèse du produit : être dans la codebase sans en comprendre pleinement les implications, c'est exactement la situation dans laquelle se trouvent les PMs quand ils écrivent leurs specs.

Sur la philosophie sous-jacente : l'idée n'est pas que les PMs deviennent développeurs. C'est que travailler avec la codebase, même superficiellement, change la qualité des questions qu'on pose.