--- title: "27 constats issus d’un audit de conseil, traités" description: "Un cabinet nordique a testé un planificateur d’IA et rendu une longue liste de défauts. Elle est devenue 27 tickets à cause racine, vérifiés en conditions réelles." url: https://torn.studio/fr/realisations/audit-conseil-27-constats locale: fr published: 2026-09-01 updated: 2026-06-25 --- # 27 constats issus d’un audit de conseil, traités > **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. **Client:** Un cabinet de conseil nordique en transformation numérique · **Livré:** 2026-06-25 **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. ## 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 | Des chiffres vérifiables | | | | --- | --- | --- | | 27 | tickets 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 / 2 | corrigé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 / 1 | tests 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. | | 4 | tickets 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. ## 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.