27 constats issus d’un audit de conseil, traités
La relation du studio au client
Le cabinet est une partie indépendante qui a évalué le plan de travail de planification de Changemkr, une plateforme dont Torn Studio détient une part et où il occupait le rôle produit. Le studio a reçu leur matériau et a mené le travail qui a suivi.
À propos du nom
Le cabinet n’a pas accepté d’être nommé, la page le décrit donc et laisse le nom de l’entreprise de côté. La description est vraie et suffit à situer d’où vient le matériau.
Réponse courte
Un cabinet nordique a testé un plan de travail de planification piloté par IA et l’a jugé peu fiable. Torn Studio en a tiré 27 tickets traçables, cherché les causes racines avant la première ligne de code, corrigé puis vérifié en conditions réelles. À la vérification du 25 juin 2026, 22 étaient corrigés, 3 partiels et 2 reportés.
La commande
Un consultant du cabinet avait testé le plan de travail et son assistant d’IA en usage réel et résumé le résultat dans une présentation. La mission était de transformer ce récit en quelque chose d’exploitable, et de pouvoir montrer ce qui avait réellement été corrigé.
Ce qui rendait la tâche difficile
- Le matériau était le récit d’une séance dans l’ordre où les choses avaient déraillé, avec 27 doléances qui pouvaient recouvrir moins de défauts ou davantage — la liste ne permettait pas de trancher.
- Le constat le plus grave était que l’assistant écrivait avoir effectué des modifications qui n’avaient jamais eu lieu, ce qui rend le reste de l’outil inutilisable quel que soit le nombre de défauts de mise en page corrigés.
- Plusieurs tickets reposaient sur des sorties de modèle qui varient d’une exécution à l’autre, et ne pouvaient donc pas être vérifiés par un test ordinaire attendant la même sortie à chaque fois.
Des chiffres vérifiables
- 27tickets issus d’un seul document de test
- TP-01 à TP-27 dans le plan de correction du dépôt, chacun portant la formulation propre du testeur et une cause racine rattachée.
- 22 / 3 / 2corrigés, partiels, reportés
- Dénombrable dans le tableau d’état du plan de correction, daté du 25 juin 2026. Deux lignes couvrent plusieurs tickets chacune, d’où 24 lignes pour 27 tickets.
- 11 / 1tests passés et ignoré
- Le rapport de vérification du dépôt nomme les sept fichiers de spécification exécutés contre la pile et la commande qui les relance.
- 4tickets qui étaient des décisions produit
- Retirés de la liste et tranchés comme décisions dans le plan, le choix et sa conséquence écrits noir sur blanc. Ils n’ont aucune correction de code.
Comment cela a été fait
Le récit est devenu des tickets traçables
Les doléances de la présentation ont été traduites en 27 tickets numérotés, TP-01 à TP-27. Chacun porte la formulation employée par le testeur, de sorte que l’on peut revenir lire ce que cette personne a réellement vu. C’est cette partie qui décide si une campagne de test mène quelque part.
Analyse avant la première ligne de code
Une passe entière s’est déroulée sans toucher au code. Chaque ticket a été rattaché à une cause racine confirmée ou supposée, les tickets partageant une cause ont été regroupés, et quatre qui se sont révélés des décisions produit ont été mis à part et tranchés comme tels. Regrouper d’abord est ce qui permet à une correction de refermer plusieurs symptômes.
Le ticket le plus dangereux d’abord
L’affirmation de modifications effectuées a été traitée avant tout le reste, car un utilisateur trompé une fois cesse de se fier à la réponse suivante. Le prompt interdit désormais cette formulation, et l’interface affiche la proposition comme non appliquée jusqu’à ce qu’une personne appuie sur le bouton.
Vérification en conditions réelles
Les corrections ont été exécutées contre l’ensemble de la pile en conteneurs, Playwright pilotant à la fois l’application web, l’API métier et le service d’IA. Onze tests sont passés et un a été ignoré, ce dernier à cause d’un geste qu’aucun navigateur sans affichage ne sait exécuter. Le rapport indique lequel et pourquoi.
Technologies
- Next.js
- React Flow
- FastAPI
- LangGraph
- Playwright
- Podman
- PostgreSQL
Jusqu’où va cette preuve
Cela montre qu’un matériau de test épars peut devenir un plan suivi ligne à ligne. Cela ne dit rien de la réussite du produit : deux tickets ont été reportés avec motif, trois sont partiellement corrigés avec le cas limite subsistant, et les trois grands parcours de création n’ont jamais été exécutés de bout en bout car ils reposent sur des sorties de modèle qui varient.
Preuves
Sur quoi repose cet article — une mesure que nous avons faite, une source datée ou une décision et son coût.
- Mesure
Combien des 27 tickets étaient corrigés à la vérification
Objet mesuré: Le tableau d’état du plan de correction du planificateur d’IA
Méthode: Compter les marques d’état du tableau et développer les lignes qui couvrent plusieurs tickets.
Résultat: 22 corrigés, 3 partiels, 2 reportés
- Décision
Mener une passe d’analyse sur toute la liste avant de toucher au code, en regroupant les tickets par cause racine.
Ce qu’elle a coûté: La passe a coûté du temps avant que quoi que ce soit paraisse corrigé, ce qui est difficile à défendre devant un commanditaire qui attend des correctifs.
- Décision
Faire présenter par l’assistant ses propositions comme non appliquées jusqu’à ce qu’une personne appuie sur le bouton.
Ce qu’elle a coûté: Chaque modification demande désormais un clic de plus, et l’objet doit d’abord être sélectionné, ce qui ralentit le parcours par rapport à un modèle qui écrirait directement.
Questions fréquentes
- Pourquoi le cabinet n’est-il pas nommé ?
- L’entreprise n’a pas accepté d’être nommée, et le nom ne figure donc pas ici. La description — un cabinet de conseil nordique en transformation numérique — est vraie et suffit à vous faire comprendre d’où vient le matériau. Le jour où une entreprise accepte, le nom y figure.
- Pourquoi l’analyse s’est-elle faite sans toucher au code ?
- Parce que 27 symptômes sont rarement 27 défauts. Le regroupement par cause racine montre où une même cause produit plusieurs symptômes, si bien qu’une correction referme plusieurs lignes. La passe a aussi mis à part quatre tickets qui se sont révélés des décisions produit, sans aucune correction de code.
- Quel a été le constat le plus grave ?
- Que l’assistant écrivait avoir effectué des modifications qui n’ont jamais eu lieu. Un défaut de mise en page se voit et se contourne, tandis qu’un accusé de réception faux conduit l’utilisateur à ne plus se fier à l’outil entier. Ce ticket a été traité en premier, et la solution tient à une règle de prompt et à un marquage visible dans l’interface.
- Que signifie partiellement corrigé dans le rapport ?
- Que le cas signalé par le testeur fonctionne, tandis qu’un cas limite voisin subsiste. Le rapport décrit ce cas limite sur la ligne. Le marquage existe parce qu’une campagne annoncée entièrement au vert rend la suivante sans valeur : celui qui lit le rapport doit voir où passe la frontière.
- Combien de temps la campagne a-t-elle duré ?
- Réception, analyse, correction et vérification ont tenu dans juin 2026, le rapport de vérification étant daté du 25. C’est le rythme qu’une personne outillée par l’IA tient sur un matériau borné où les tickets sont déjà décrits par quelqu’un qui a utilisé le produit.
Dites-nous ce que vous voulez construire
Trente minutes, sans frais, et une réponse franche sur le fait que nous soyons ou non le bon studio.
Réponse sous 24 heures, une proposition écrite à prix fixe sous trois jours, et vous décidez à votre rythme.
Garantie de satisfaction