Baptiste BouaultDossier technique, 2026 EN English

Baptiste Bouault, ingénieur IA et CTO d’une startup IA B2B

planches, dont 5 systèmes en production ou en pilote chez des clients

Voir les planches
Titre
Baptiste BouaultIngénieur IA, CTO d’une startup IA B2B
Objet
Des agents IA en production chez des clients : téléphone, audit, achats. Le modèle propose, le code décide.
Échelle
1 point = 1 commit versionné
Contact
Écrire
Cannes
--:--
Lisbonne
--:--
  1. Avril : Mission de conseil : analytics pour un réseau national de distribution
  2. Mai : Arbitrage de fusions-acquisitions, projet personnel
  3. 1er juillet : CTO d’une startup IA
  4. 6 août : Plateforme pour salles de sport : premier commit
  5. 30 septembre : Pilote de la plateforme installé

Nomenclature

Planches

Dix-sept systèmes, chacun avec son schéma, son analyse et ses limites. Une ligne marquée d’une référence s’ouvre sur sa planche.

Les points de la page de garde sont les 1 839 commits versionnés en 2026 dans 35 dépôts : une trace d’activité, pas une mesure du travail. Une partie se fait sur les machines de production, hors de ces dépôts.

  1. Startup IA, rôle de CTO9 pièces

    1. S1Réceptionnistes vocalesAgents vocaux qui réservent, annulent et transfèrent, pour cinq clients.En productionFin juin à octobre 2026
    2. S2Plateforme pour salles de sportPlateforme multi-structures ; isolation imposée par la base et cassée exprès.PiloteAoût à septembre 2026
    3. S3Intelligence d’auditAgent normatif qui cite les normes au paragraphe, pour un cabinet d’audit.En productionJuillet à septembre 2026
    4. S4Papiers de travail d’auditSélection des tiers à confirmer, acceptée sur dossiers réels.LivréFin juillet à août 2026
    5. S5Achats pour la restaurationDes messages des chefs aux commandes, factures lues deux fois.PiloteJuillet à octobre 2026
    6. S6Garde-fous pour agents de codeRevue de sécurité par agents ; portier fermé par défaut.PrototypeAoût à octobre 2026
    7. S7Plan de contrôle d’exploitationSupervision des agents en production, spécifiée.SpécificationJuillet à septembre 2026
    8. S8Exercice technique à correcteur cachéCorrecteur à tests cachés, prouvé rouge puis vert.LivréSeptembre 2026
    9. S9Un site où chaque fait a sa sourceSite d’entreprise où un fait sans source efface son bloc.ConstruitAoût à octobre 2026
  2. Conseil, Ascend Partners7 pièces

    1. C1Plateforme d’analytics localeAnalyse et simulation d’un réseau de magasins ; le modèle ne calcule rien.LivréAvril à juin 2026
    2. C2GEO AuditCe que répondent les moteurs génératifs, sans leur souffler la marque.LivréMai à juin 2026
    3. C3Audit d’un moteur de scoring héritéUn moteur VBA reproduit au centième avant d’en chercher la cause.Livré2026
    4. C4Chaîne de présentationsNotes de consultants vers présentations ; charte séparée des règles.PrototypeMai 2026
    5. C5Agents de recherche pour une équipeAgents et skills pour une équipe de conseil ; orchestration repensée.LivréMars à mai 2026
    6. 15Veille des réseaux sociauxVeille hebdomadaire pour l’équipe marketing d’un client de mission : transcription locale des vidéos, briefs éditoriaux.
    7. 16Outil d’évaluation de résilienceCalculatrice d’évaluation pour le site du cabinet : moteur de notation et tests.
  3. Projets personnels et indépendants11 pièces

    1. P1Pré-revue de conformitéPré-revue de supports marketing, évaluée contre une vérité terrain.PrototypeSeptembre 2026
    2. P2Site d’un concessionnaire nautiqueStock mis à jour par fiche PDF ; lecteur sans dépendance.En productionAoût à septembre 2026
    3. P3Arbitrage de fusions-acquisitionsLecture d’offres publiques en trois juridictions ; arrêté sur ses mesures.PrototypeMai à juin 2026
    4. 20Site de Cinq.Site de l’activité indépendante, page statique.
    5. 21Ce portfolioCe dossier : page statique générée par script, en français et en anglais.
    6. 22Site de réservation de visites guidéesSite bilingue sans dépendance, paiement en ligne, chaque montant recalculé côté serveur. 26 tests.
    7. 23Simulateur de cicatrisation 3DPrototype : modèle paramétrique tiré de la littérature, ses contraintes écrites en tests.
    8. 24Pipeline de prospectionSourcing sur données publiques et enrichissement ; aucun envoi sans revue humaine. 205 tests.
    9. 25Application d’entraînementSuivi d’entraînement personnel : connexion par lien magique, isolation au niveau des lignes. Prototype.
    10. 26Bots de tradingBots personnels : la troisième version a été arrêtée après mesure d’une espérance négative, frais compris.
    11. 27Autres outils personnelsAgrégateur d’annonces, vérification de contacts.

Terrains

Clients

Chaque client, anonymisé : ce qui a été livré, où ça en est, et ce que ce terrain a appris.

Les noms restent chez les clients. Les statuts sont datés ; un système qui ne tourne pas encore est dit comme tel.

  1. Club de sport, deux sitesRéceptionniste vocale qui réserve et annule dans son logiciel ; plateforme appelée à le remplacer

    Voix en production depuis juin 2026 ; plateforme en pilote depuis le 30 septembre

    Le modèle se trompait sur les longs préavis : la décision est passée au code.

    S1S2

  2. Revendeur informatiqueStandard vocal : transferts et messages

    En service depuis juillet 2026

    Les transferts sont réels : un appel de test fait sonner de vraies personnes.

    S1

  3. Maison de ventes aux enchèresAssistante vocale sous cahier des charges « zéro invention »

    Mise en service visée mi-octobre 2026

    Un modèle plus récent inventait une date : le modèle se choisit sur le cahier des charges.

    S1

  4. RestaurantCommandes à emporter par téléphone

    En service

    Une fermeture estivale se programme : bascule préparée à l’avance, exécutée le 2 août.

    S1

  5. Distributeur de pièces automobilesStandard vocal

    En service

    Une réponse dans une voix étrangère : les langues de chaque client sont désormais fixées.

    S1

  6. Cabinet de commissaires aux comptesAgent normatif et correctifs de la saisie des temps

    En production

    Une année absente a daté des heures un an trop tôt : toute date passe par une fenêtre de plausibilité.

    S3

  7. Cabinet membre d’un réseau internationalSélection des tiers à confirmer

    Pilote mené en juillet et août 2026

    Le seul juge accepté : retrouver la sélection faite à la main par l’auditeur.

    S4

  8. Groupe de restauration multi-sitesCommandes des chefs, lecture des factures

    Pilote

    Les erreurs qui coûtent sont la date, l’aperçu et le total.

    S5

  9. Réseau national de distributionAnalytics locale et simulation ; mesure de présence dans les moteurs génératifs

    Livré en juin 2026

    Un chiffre indéfendable ne s’affiche pas, même avec une réserve.

    C1C2

  10. Une grande institutionAudit d’un moteur de scoring hérité

    Livré en 2026

    Reproduire au centième avant de conclure.

    C3

  11. Groupe industriel et groupe mutualisteBenchmarks multi-agents, audit d’une grille de notation

    Livrés au printemps 2026

    Les agents ne s’orchestrent pas en cascade : la session principale les lance.

    C5

  12. Concessionnaire de bateaux, entreprise familialeSite, stock mis à jour par fiche PDF

    En production depuis le 17 août 2026

    L’audit du jour de mise en ligne a trouvé les failles du site lui-même.

    P2

  13. Courtier en valeurs américain, hackathonPré-revue de conformité des supports marketing

    Prototype, septembre 2026

    Un corpus écrit par l’auteur des règles reste un banc de régression.

    P1

Notes générales

Notes

Valables pour toutes les planches. Chacune est illustrée au moins une fois sur un schéma.

  1. 1

    Le modèle propose, le code décide : préavis, capacité, plafonds et montants sont calculés par du code.

  2. 2

    Aucune confirmation n’est donnée avant que le geste ait été exécuté et relu.

  3. 3

    Une isolation se prouve en la cassant exprès : une régression injectée doit faire échouer la suite.

  4. 4

    Toute action qui touche la production attend un feu vert explicite et nommé, à chaque fois.

  5. 5

    Un chiffre affiché porte sa source et son mode de mesure ; sans source, il disparaît, y compris ici.

  6. 6

    Les garde-fous sont attaqués par leur auteur : chaque contournement trouvé devient un test avant son correctif.

Boucle de livraison

Chaque livraison suit la même boucle : une spécification datée, l’exécution, une preuve machine, puis un feu vert explicite avant la production.

Exemple, planche S3 : le 17 juillet, des heures saisies sans année sont datées un an trop tôt. Les garde-fous sont écrits avec leur plan de retour arrière, prouvés en tests, en production le 20 juillet ; le journal qui aurait raconté l’incident arrive le 21.

Révisions

Parcours

Conseil, une première startup cofondée puis dissoute, aujourd’hui CTO d’une startup IA B2B, entre Cannes et Lisbonne.

Le chiffre d’utilisateurs de la première startup est celui de la société ; il n’a pas de dépôt consultable.

Rév.DateObjet
EJuil. 2026Startup IA B2BCTO et ingénieur IA, depuis juillet 2026Seul ingénieur de l’équipe : agents vocaux en production et plateformes métier pour l’audit, le sport et la restauration.
DJanv. 2026Ascend PartnersConsultant IA et data, de janvier à juillet 2026Stage de fin d’études : missions pour de grands comptes, outils d’analyse et d’agents.
C2026ESSECGlobal BBA, diplômé en 2026Spécialisation data et IA.
B2025UC BerkeleySemestre d’échange
A2025RhinovateCofondateur et COO d’une première startupHealthtech passée par Founders Inc à San Francisco. 2 500 utilisateurs payants en trois mois. Société dissoute en 2026.
Plan de situation
LisbonneCannes
  • Agents

    Agents vocaux en temps réel, systèmes multi-agents avec validation humaine, évaluation contre une vérité terrain, garde-fous pour agents de code.

  • Ingénierie

    Python, FastAPI ; PostgreSQL et sécurité au niveau des lignes ; TypeScript, React, Next.js ; téléphonie et voix ; DuckDB, simulation multi-agents.

  • Conseil

    Benchmarks de solutions IA, présentations de comité, modélisation de scénarios, mesure de présence dans les moteurs génératifs.

Parlons-en.

baptiste.bouault@gmail.com

S1

Réceptionnistes vocales

Des agents vocaux qui décrochent, identifient l’appelant, réservent ou annulent dans le logiciel du client, transfèrent ou prennent un message. Une même lignée de moteur, adaptée client par client.

En production. Chez un club de sport depuis début juin 2026, au standard d’un revendeur informatique depuis juillet, puis chez d’autres clients.

Planche
S1
Statut
En production
Nature
Produit client
Période
Fin juin à octobre 2026
Rôle
Reprise du portefeuille voix fin juin 2026 : garde-fous, correctifs de production, mesures, nouveaux déploiements. Le premier moteur est antérieur à mon arrivée.
Contexte
Startup IA, rôle de CTO
Pile
Python, FastAPI, WebSocket, téléphonie temps réel, reconnaissance et synthèse vocales, modèle à outils
Historique
Dépôts de la startup sous une identité d’équipe partagée ; une partie des correctifs est écrite directement sur les machines de production.
Dernière révision
11 sept. 2026
Diffusion
Publique, zones hachurées retenues

SchémaChronogramme d’un appel

Lecture Le temps court de gauche à droite. Chaque couloir est un composant ; un losange est une décision du code. La parole de l’agent ne commence qu’après l’écriture relue.

Reconstitution à données fictives. Le comportement est celui du système ; les règles, seuils et consignes réels sont retenus.

Analyse

Ce que la planche ne dit pas d’elle-même

Le vrai problème

Au téléphone, chaque phrase engage le client et le moindre blocage s’entend. Le modèle comprenait bien les demandes, mais il se trompait sur l’arithmétique des délais : il lisait correctement l’heure de la séance, puis annonçait gratuite une annulation qui serait facturée.

Le second risque était mécanique : une entrée-sortie bloquante sur le chemin de la parole suffit à figer le flux audio, et l’appelant n’entend plus rien.

Décisions

  1. RetenuLe verdict de préavis est formulé par le code ; le modèle le transmet sans recalculer.

    ÉcartéRemettre l’horodatage en tête des consignes. Essayé, puis retiré.

    PourquoiSur 180 tirages, le modèle se trompait 8 fois sur 8 au-delà de 8 h de préavis et 0 fois sur 8 à 2 h : l’erreur n’apparaît qu’aux longs délais, il fallait la mesurer pour la voir.

  2. RetenuToute entrée-sortie du tour de parole passe hors de la boucle d’événements.

    ÉcartéGarder des appels synchrones, plus simples à lire.

    PourquoiUn appel synchrone sur la boucle affame le flux audio et coupe la transcription. Mesuré hors ligne : 645 ms de gel à l’ouverture d’un appel avant correction, 29 ms après.

  3. RetenuPour la maison de ventes, le modèle standard.

    ÉcartéUn modèle plus récent, puis un modèle léger.

    PourquoiLe plus récent inventait une date ; le léger échouait à 13 contrôles sur 16 du cahier des charges.

Ce qui a cassé

  1. 10 juillet

    Une fausse confirmation d’annulation est dite en production. Trois chemins silencieux restaient ouverts ; ils sont fermés le 6 août, et depuis rien n’est confirmé avant que l’écriture ait été relue.

  2. 12 juillet

    Cascade de silences en production, jusqu’à environ 21 secondes : une lecture bloquante figeait la boucle d’événements. Toutes les entrées-sorties du tour de parole sont sorties de la boucle.

Limites à ce jour

  • Un dépôt par client : un correctif se reporte encore à la main d’un dépôt à l’autre.
  • À la mi-juillet, les chemins de refus n’étaient pas tous éprouvés sur de vrais appels ; ils restent surveillés dans le journal.
  • Aucun volume d’appels publié : ces chiffres appartiennent aux clients.
  • Git ne sépare pas mon travail de celui du dirigeant de la startup : les commits partagent une identité d’équipe.

Terrains

ClientCe qui tourneStatut daté
Club de sport, deux sitesRéservations et annulations écrites dans son logiciel de réservation, puis relues ; une annulation tardive part en alerte à l’équipe.En production depuis début juin 2026
Revendeur informatiqueStandard : transferts vers la bonne personne et messages ; la consultation de factures attend le client.En service depuis juillet 2026
Maison de ventes aux enchèresCahier des charges « zéro invention » : l’assistante n’estime jamais une pièce et transfère dès qu’une information manque.Transferts actifs le 11 septembre ; mise en service visée mi-octobre
RestaurantCommandes à emporter par téléphone ; fermeture estivale programmée puis basculée.En service ; bascule exécutée le 2 août 2026
Distributeur de pièces automobilesMême lignée de moteur ; langues de l’organisation fixées après une réponse dans une voix étrangère.En service

Cotesmesures et dénombrements, avec leur mode de mesure

645 → 29 msgel de la boucle d’événements à l’ouverture d’un appel, avant et après correction. Le « avant » est reproduit en banc par huit lectures simulées de 80 ms.mesuré hors ligne
8 / 8erreurs quand le modèle annonçait lui-même un préavis de plus de 8 h ; 0 sur 8 à 2 h. 180 tirages au total.mesuré hors ligne
21 sordre de grandeur du plus long silence de l’incident du 12 juillet, avant correctiondocumenté par le projet

Révisions

F11 sept. 2026Transferts actifs pour la maison de ventes
E10 août 2026Cahier des charges « zéro invention » pour la maison de ventes
D6 août 2026Plus aucune confirmation avant écriture relue
C12 juil. 2026Cascade de silences : entrées-sorties sorties de la boucle
B10 juil. 2026Fausse confirmation d’annulation en production
A22 juin 2026Reprise du portefeuille voix

Nomenclaturecomposants

  1. 01Téléphonie temps réeldécroche, diffuse l’audio dans les deux sens
  2. 02Transcriptionsuit la langue de l’appel ; bascule sur demande explicite
  3. 03Modèle à outilscomprend l’intention et propose une action
  4. 04Règles en codepréavis, capacité réelle, unité du membre
  5. 05Pont vers le logiciel du clientécriture gardée puis relue
  6. 06Garde de languela réponse sort dans la langue de l’appel
  7. 07Synthèse vocaleparle après le geste exécuté
  8. 08Consignes du modèlecontenu retenu
  9. 09Seuils métiercontenu retenu

Notes

  1. Le modèle propose, le code décide : préavis, capacité et unité sont calculés par le code.
  2. Aucune confirmation n’est dite avant que l’écriture ait été exécutée et relue.
  3. Une information manque : l’appel est transféré ou un message est pris.
  4. Redémarrer, changer les consignes ou la configuration en production demande un feu vert explicite, à chaque fois.

Zones hachurées

Ce que cette planche ne montre pas, et ne montrera pas :

  • Consignes et exemples donnés au modèle
  • Seuils de préavis et règles de chaque client
  • Noms, numéros et données des appelants
  • Intégration avec le logiciel du client
  • Volumes d’appels

Ce que ça montre

Mesurer où le modèle se trompe, puis lui retirer la décision.

Planche suivante, S2Plateforme pour salles de sport

S2

Plateforme pour salles de sport

Back-office, API, application membre et coach, moteur de programmes : une plateforme multi-structures pour un club de sport à deux sites. L’isolation entre structures est imposée par la base de données, et prouvée en la cassant exprès.

Pilote. Installé le 30 septembre 2026 sur les données réelles, en lecture seule. L’ancien logiciel reste la source de vérité ; aucune date de bascule n’est fixée.

Planche
S2
Statut
Pilote
Nature
Plateforme client
Période
Août à septembre 2026
Rôle
CTO : architecture, isolation, livraison du pilote
Contexte
Startup IA, rôle de CTO
Pile
Python, PostgreSQL et sécurité au niveau des lignes, 86 migrations, application rendue côté serveur, moteur de programmes en TypeScript sans dépendance
Historique
Versionné dans les dépôts de la startup.
Dernière révision
30 sept. 2026
Diffusion
Publique, zones hachurées retenues

SchémaPlan de l’isolation

Lecture Vue en plan. Les murs hachurés sont les politiques d’accès de la base : une structure ne voit que sa pièce. Le couloir est l’API ; le journal ne reçoit que des ajouts.

Reconstitution à données fictives. Le comportement est celui du système ; les règles, seuils et consignes réels sont retenus.

Analyse

Ce que la planche ne dit pas d’elle-même

Le vrai problème

Remplacer le logiciel de réservation d’un client en service sans jamais écrire deux fois la même vérité, alors que ce logiciel renvoie ses échecs avec un code de succès.

Et tenir une isolation entre structures que la base peut contourner en silence : la première suite passait ses 44 assertions sur une base qui fuyait.

Décisions

  1. RetenuL’isolation est imposée par la base, migrations exécutées sous le rôle propriétaire.

    ÉcartéUn super-utilisateur qui change de rôle, puis une garde par expression régulière.

    PourquoiLe changement de rôle sautait au premier « commit » ; la garde par motif a été contournée de cinq façons au contre-audit.

  2. RetenuLa double écriture est refusée par des déclencheurs qui regardent l’état résultant.

    ÉcartéLaisser la règle au code d’import.

    PourquoiTrois mises à jour contournaient un déclencheur posé sur la seule insertion.

  3. RetenuLa couche IA est installée mais éteinte, avec un plafond par structure.

    ÉcartéLes 24 capacités IA proposées au départ.

    Pourquoi18 ont été abandonnées faute de besoin produit.

Ce qui a cassé

  1. 6 août

    Le premier audit trouve 8 défauts dans l’isolation, puis 8 autres dans les correctifs eux-mêmes.

  2. 25 août

    Six sondes sur neuf lisaient une autre structure en changeant l’identifiant dans l’adresse. Corrigé avant toute mise en service.

  3. 8 septembre

    Deux régressions injectées sur trois passaient inaperçues : le faux serveur de test était trop permissif, et environ 1 200 tests verts n’avaient rien vu. La suite a été durcie.

  4. 29 septembre

    Un membre pouvait modifier la réservation d’un autre membre. Corrigé la veille de l’installation.

Limites à ce jour

  • Pas de date de bascule : la plateforme ne remplace pas encore l’ancien logiciel.
  • Les applications tournent sur une organisation de démonstration ; l’appel de l’agent vocal vers l’API est simulé.
  • Une intégration d’e-mailing n’a jamais été confrontée à une vraie réponse ; deux échecs de tests connus restent ouverts.
  • Le moteur de programmes porte 67 valeurs à calibrer, pas encore relues par un préparateur physique.

Terrains

ClientCe qui tourneStatut daté
Club de sport, deux sitesPlateforme réelle en lecture seule, à côté de l’ancien logicielPilote installé le 30 septembre 2026
Salles fictivesMoteur de programmesPrototype du 9 septembre 2026

Cotesmesures et dénombrements, avec leur mode de mesure

78 / 78régressions injectées volontairement dans l’isolation, toutes détectées, au 8 septembremesuré hors ligne
261 / 261assertions d’isolation entre structures, passées de 18 à 50 puis 261mesuré hors ligne
3 872tests du back-office et de l’API au 30 septembre, avec 2 échecs connus restés ouvertsmesuré hors ligne
2 571tests de l’application membre et coachmesuré hors ligne
455tests du moteur de programmes, exécution rapportée le 9 septembremesuré hors ligne
57 / 648séances générées hors du budget de temps, sur les salles fictivesmesuré hors ligne

Révisions

F30 sept. 2026Installation du pilote, en lecture seule
E29 sept. 2026Audit de l’application : accès croisés entre membres corrigés
D9 sept. 2026Prototype du moteur de programmes
C8 sept. 2026Suite d’isolation durcie : 78 régressions injectées, 78 détectées
B26 août 2026Première démonstration, sur données fictives
A6 août 2026Premier commit du back-office, premier audit d’isolation

Nomenclaturecomposants

  1. 01Isolation par la basechaque structure ne voit que ses lignes, imposé par la base elle-même
  2. 02APIrefus motivés, idempotence, journal en ajout seul
  3. 03Miroir de l’existantlecture seule, l’ancien logiciel reste la référence
  4. 04Couche IAéteinte par défaut, budget par structure
  5. 05Validation humaineun envoi sans validateur ne peut pas être écrit
  6. 06Application membre et coachaucune logique métier locale
  7. 07Moteur de programmesmême entrée, même programme ; fonctionne sans IA
  8. 08Schéma et règlescontenu retenu

Notes

  1. L’isolation est imposée par la base et prouvée par des régressions injectées.
  2. Un envoi rédigé par le modèle ne peut pas être écrit sans validateur humain.
  3. Le moteur fonctionne sans IA ; l’IA départage des exercices équivalents et rédige les consignes.

Zones hachurées

Ce que cette planche ne montre pas, et ne montrera pas :

  • Schéma de données et politiques d’accès
  • Règles métier et règles bien-être
  • Nom, unités et chiffres du client
  • Logiciels tiers remplacés

Ce que ça montre

Refuser un test vert qui n’a jamais été rouge : la suite d’isolation a été cassée exprès dès le premier jour.

Planche suivante, S3Intelligence d’audit

S3

Intelligence d’audit

Une plateforme pour un cabinet de commissaires aux comptes : portefeuille, saisie des temps par agent, diligences. J’y ai ajouté un agent normatif qui trie les programmes de travail en citant les normes au paragraphe.

En production. Plateforme en service depuis juin 2026, lancée par le dirigeant de la startup ; associés en accès restreint depuis le 9 juillet. Comptes individuels prévus en octobre.

Planche
S3
Statut
En production
Nature
Plateforme client
Période
Juillet à septembre 2026
Rôle
Module d’agent normatif (corpus, tri, citations) et correctifs de production sur la saisie des temps
Contexte
Startup IA, rôle de CTO
Pile
Python, FastAPI, SQLite plein texte, extraction PDF, appariement flou
Historique
Dépôt de la startup ; le module normatif est développé sur la machine de production dédiée au client et n’est pas versionné.
Dernière révision
18 sept. 2026
Diffusion
Publique, zones hachurées retenues

SchémaRègles graduées

Lecture En haut, le calendrier de saisie : la zone hachurée est hors de la fenêtre de plausibilité, la jauge est le total du jour. En bas, le corpus : chaque arc relie une procédure au paragraphe cité.

Reconstitution à données fictives. Le comportement est celui du système ; les règles, seuils et consignes réels sont retenus.

Analyse

Ce que la planche ne dit pas d’elle-même

Le vrai problème

Le 17 juillet, des heures facturables saisies sans année (« le 14/07 ») ont été datées un an trop tôt. Invisibles dans le contrôle mensuel, elles n’ont été retrouvées que par les journaux du serveur.

Côté normes, une citation fausse coûte plus cher qu’une absence de réponse : un auditeur doit pouvoir ouvrir le paragraphe cité.

Décisions

  1. RetenuUne fenêtre de plausibilité, seule porte de reconfirmation des dates.

    ÉcartéExiger que l’année soit celle de l’exercice audité.

    PourquoiUne saisie de janvier pour décembre est légitime ; la règle simple aurait bloqué des saisies justes.

  2. RetenuUn journal en ajout seul qui trace aussi les échecs.

    ÉcartéUn journal des seules écritures réussies.

    PourquoiLe 17 juillet, il aurait été vide : ce sont les échecs qui racontaient l’incident.

  3. RetenuLe bilan affiché reprend le regroupement du logiciel d’audit.

    ÉcartéUn cumul net calculé par la plateforme.

    PourquoiLe cumul s’écartait du bilan déposé de plusieurs centaines de milliers d’euros ; ailleurs, un bilan juste au centime ne l’était que par coïncidence.

Ce qui a cassé

  1. 17 juillet

    Heures fantômes datées un an trop tôt, et une même ligne supprimée 18 fois en une seconde. Garde-fous en production le 20 juillet, journal le 21, avec un plan de retour arrière écrit.

  2. 20 juillet

    Sans un fichier absent du plan initial, l’idempotence serait redevenue inerte au redémarrage, suite de tests verte comprise.

  3. 23 juillet

    Ni plafond côté serveur ni pagination de la bibliothèque : 1 430 résultats s’affichaient comme 60. Corrigés.

Limites à ce jour

  • Comptes individuels pas encore en place : l’agent normatif s’ouvrira aux autres utilisateurs ensuite.
  • Les citations sont contrôlées au tri et à la suggestion de travail ; une question libre ne passe pas par ce contrôle.
  • Le module normatif n’est pas versionné, et la dette de sécurité du dépôt est connue et suivie.

Terrains

ClientCe qui tourneStatut daté
Cabinet de commissaires aux comptesPlateforme du cabinet, module normatif, saisie des temps par agentEn production ; associés en accès restreint depuis juillet 2026

Cotesmesures et dénombrements, avec leur mode de mesure

137documents du corpus, normes et procédures, découpés en environ 6 112 segmentsdocumenté par le projet
7associés en périmètre restreint le 9 juilletdocumenté par le projet
1 430correspondances qu’une recherche de la bibliothèque affichait comme 60, avant la pagination du 23 juilletdocumenté par le projet
108routes de la plateforme, hors module normatifcompté dans le dépôt

Révisions

F18 sept. 2026Présentation à l’ensemble du cabinet
E23 juil. 2026Plafond serveur et pagination corrigés
D20 juil. 2026Garde-fous de saisie en production
C17 juil. 2026Incident : heures fantômes
B15 juil. 2026Module normatif : corpus, tri, suggestion de travail
A9 juil. 2026Associés en accès restreint

Nomenclaturecomposants

  1. 01Référentiel clients du cabinetle portefeuille du cabinet fait foi
  2. 02Agent de tempsextraction, appariement flou, carte de confirmation
  3. 03Règles puresplafond du jour, fenêtre de plausibilité, année absente
  4. 04Journal en ajout seulimposé par la base ; un échec est tracé sans casser la requête
  5. 05Corpus normatifrecherche plein texte, référence au paragraphe
  6. 06Contrôle des citationstoute référence absente du corpus est retirée et tracée
  7. 07Seuils et consignescontenu retenu

Notes

  1. Seule la confirmation écrit ; rejouée, elle n’écrit qu’une fois.
  2. Une citation n’existe que si son paragraphe existe dans le corpus.
  3. Après deux bilans divergents, la vue reproduit le regroupement du logiciel d’audit.

Zones hachurées

Ce que cette planche ne montre pas, et ne montrera pas :

  • Cabinet, collaborateurs et entités auditées
  • Consignes du modèle et seuils
  • Logiciels tiers et leurs données
  • Bilans et montants réels

Ce que ça montre

Transformer un incident de données d’auditeurs en règles calculées et en journal inaltérable, déployés avec un plan de retour arrière.

Planche suivante, S4Papiers de travail d’audit

S4

Papiers de travail d’audit

Pour un second cabinet, membre d’un réseau international : reproduire sa méthode de sélection des tiers à confirmer, sur ses propres dossiers, sans donnée synthétique et sans écrire dans son logiciel d’audit.

Livré. Phase pilote menée du 28 juillet au 3 août 2026, avec 11 cas d’acceptation verts sur dossiers réels. Le dirigeant de la startup l’a étendue ensuite ; elle était encore active fin septembre.

Planche
S4
Statut
Livré
Nature
Plateforme client
Période
Fin juillet à août 2026
Rôle
Pilotage par lots de la phase pilote, moteurs de sélection, acceptation sur dossiers réels
Contexte
Startup IA, rôle de CTO
Pile
Python, FastAPI, SQLite, pandas, lecteurs de balances, typage strict
Historique
Code sur le dépôt de la startup depuis le 10 août ; les commits du pilote ont été perdus à l’import.
Dernière révision
3 août 2026
Diffusion
Publique, zones hachurées retenues

SchémaLigne d’échantillonnage

Lecture Les comptes de tiers sont posés bout à bout, chacun à la longueur de son solde. Les lettres marquent les critères ; les traits verticaux, le pas de l’échantillonnage en unités monétaires sur le reste.

Reconstitution à données fictives. Le comportement est celui du système ; les règles, seuils et consignes réels sont retenus.

Analyse

Ce que la planche ne dit pas d’elle-même

Le vrai problème

Reproduire la méthode d’un cabinet, critères cumulables et échantillonnage en unités monétaires, sur six formats de balance différents. La spécification n’est arrivée qu’avec l’extraction des dossiers.

Le seul juge admis : retrouver, sur dossiers réels, la sélection que l’auditeur avait faite à la main.

Décisions

  1. RetenuDes critères indépendants : une entité peut porter plusieurs marques.

    ÉcartéUn ordre séquentiel, où une entité retenue sort de la population.

    PourquoiUn seul motif par entité ne correspondait pas aux papiers du cabinet.

  2. RetenuSoldes d’ouverture comparés par classe et compte par compte.

    ÉcartéLa comparaison par classe seule.

    PourquoiLe cumul par classe masque les reclassements entre comptes.

  3. RetenuTotaux calculés sur toute la population, avec une contre-preuve indépendante.

    ÉcartéLe total des cent premiers comptes, affiché comme total.

    PourquoiIl manquait une partie du solde ; la contre-preuve l’a montré.

Ce qui a cassé

  1. 31 juillet

    L’ordre provisoire codé la nuit est contredit par les papiers réels : moteur réécrit le jour même.

  2. Questionnaire et modèle de lettre absents du partage : pré-remplissage et lettres non faits pendant le pilote.

  3. 4 août

    Correctifs faits sur la machine seule ; les commits du pilote ont été perdus à l’import du 10 août.

Limites à ce jour

  • Un critère est recopié du papier de l’auditeur ; un autre est vérifié par appartenance au résiduel, sans recalcul strict.
  • Une exception attend une décision humaine.
  • Les tests d’acceptation se sautent sans les données réelles : ils ne tournent que chez le client.
  • Les lettres de confirmation ont été ajoutées après le pilote, par le dirigeant de la startup.

Terrains

ClientCe qui tourneStatut daté
Cabinet membre d’un réseau internationalPilote de sélection des tiers, puis extension par le dirigeant de la startupPilote mené du 28 juillet au 3 août 2026 ; actif fin septembre
Troisième cabinetPrototype d’un jour sur l’architecture du pilote, par le dirigeant de la startupNon déployé

Cotesmesures et dénombrements, avec leur mode de mesure

11 / 11cas d’acceptation verts le 31 juillet sur dossiers réels : 3 formulaires, 7 populations, 1 chaîne complètemesuré hors ligne
3formulaires de confirmation reproduits à l’identiquemesuré hors ligne
0écart par classe sur les soldes d’ouverture des deux dossiers testés ; un reclassement trouvé au détail par comptemesuré hors ligne
0donnée synthétique, hors bornes légales : l’acceptation sur dossiers réels fait foidocumenté par le projet

Révisions

D3 août 2026Code gelé pour la démonstration, fin du pilote
C31 juil. 2026Moteur réécrit, 11 cas d’acceptation verts
B29 juil. 2026Principe du test d’acceptation fixé
A28 juil. 2026Début de la phase pilote, par lots

Nomenclaturecomposants

  1. 01Lecture des dossiersdossiers du cabinet, logiciel d’audit en lecture seule
  2. 02Normalisationun format inconnu est refusé, jamais deviné
  3. 03Moteurs purstransformations sans entrée-sortie, testables seules
  4. 04Sélectioncritères cumulables, puis échantillonnage en unités monétaires sur le résiduel
  5. 05Contre-preuvetotaux recalculés indépendamment sur toute la population
  6. 06Grille de critères du cabinetcontenu retenu

Notes

  1. Zéro donnée synthétique : seule l’acceptation sur dossiers réels compte.
  2. Les règles du cabinet sont reproduites telles quelles, y compris plusieurs marques pour une même entité.
  3. Sans clé d’API, une exception est levée avant tout appel réseau.

Zones hachurées

Ce que cette planche ne montre pas, et ne montrera pas :

  • Cabinet, réseau et logo
  • Entités, montants et captures de dossiers
  • Grille des critères de sélection

Ce que ça montre

Piloter un agent par lots jusqu’à reproduire les papiers réels d’un cabinet ; l’architecture posée pendant le pilote a servi à un autre cabinet.

Planche suivante, S5Achats pour la restauration

S5

Achats pour la restauration

Les messages des chefs deviennent des commandes, et les factures des fournisseurs sont lues pour être rapprochées. Un humain valide avant tout envoi.

Pilote. Capture des commandes et lecture des factures en usage depuis l’été 2026 dans un groupe de restauration multi-sites. L’écriture comptable n’est pas encore en service.

Planche
S5
Statut
Pilote
Nature
Plateforme client
Période
Juillet à octobre 2026
Rôle
Fiabilisation des montants, des dates et des envois ; l’interface est surtout écrite par le dirigeant de la startup
Contexte
Startup IA, rôle de CTO
Pile
Next.js, React, TypeScript pour l’interface ; service de lecture et de rapprochement séparé
Historique
Interface versionnée dans un dépôt de la startup ; le service est hébergé sur une machine de la startup.
Dernière révision
29 sept. 2026
Diffusion
Publique, zones hachurées retenues

SchémaRapprochement en trois colonnes

Lecture Dans l’ordre du flux : le message du chef, la commande structurée, la facture lue deux fois. Dessous, le total garde l’état de chaque montant.

Reconstitution à données fictives. Le comportement est celui du système ; les règles, seuils et consignes réels sont retenus.

Analyse

Ce que la planche ne dit pas d’elle-même

Le vrai problème

Les chefs écrivent en texte libre, avec des calibres faciles à confondre. Sur les factures, le nom imprimé n’est pas toujours celui de l’émetteur légal.

Les erreurs qui coûtent sont précises : une commande envoyée deux fois, un montant inventé, une livraison datée du mauvais jour.

Décisions

  1. RetenuL’envoi se fait par référence : le serveur recompose le texte, l’aperçu est exactement ce qui part.

    ÉcartéEnvoyer le texte affiché à l’écran.

    PourquoiUn écart entre l’aperçu et l’envoi est invisible pour celui qui valide.

  2. RetenuLa date de livraison est calculée sur le fuseau du restaurant.

    ÉcartéLe fuseau de la machine ou du navigateur.

    PourquoiSur une machine en temps universel, une commande passée entre minuit et une heure partait pour la veille.

  3. RetenuUn total à états : confirmé, estimé, partiel ou sans prix.

    ÉcartéLa somme brute des lignes.

    PourquoiUne commande à moitié cotée affichait 0,08 € de total.

  4. RetenuLe fournisseur est identifié par le numéro fiscal lu dans le QR de la facture.

    ÉcartéLe nom imprimé.

    PourquoiLe nom imprimé n’est pas toujours l’émetteur légal.

Ce qui a cassé

  1. 10 août

    Un caractère invisible dans un texte collé faisait échouer la recherche d’un article : la recherche s’ouvre désormais pré-remplie et nettoyée.

  2. La machine de 2 Go tombait sous la charge : les appels passent par lots de trois.

  3. Un écran de tri des documents est activé puis suspendu : ses suggestions étaient fausses.

  4. 29 septembre

    Le total « 0,08 € » d’une commande à moitié cotée est remplacé par le total à états.

Limites à ce jour

  • L’écriture dans l’ERP n’est pas en service : la liaison reste inactive sur la branche principale.
  • L’envoi réel aux fournisseurs n’était que proposé à la mi-août ; il n’est pas prouvé ici.
  • Accès de démonstration et aucun test automatisé dans l’interface.

Terrains

ClientCe qui tourneStatut daté
Groupe de restauration multi-sitesCapture des commandes des chefs ; lecture des factures ; rapprochement préparéCommandes en usage depuis juillet 2026 ; écriture comptable non active

Cotesmesures et dénombrements, avec leur mode de mesure

6étapes du suivi d’une commande, de reçue à closecompté dans le dépôt
2lectures indépendantes par facture, comparées ligne à lignedocumenté par le projet
1tentative d’envoi par clic ; un renvoi manuel passe par une confirmationcompté dans le dépôt

Révisions

D29 sept. 2026Total à états fusionné
C13 août 2026État du pilote : écriture ERP bloquée par une licence
B5 août 2026Envoi en mode test
Ajuil. 2026Capture des commandes en usage

Nomenclaturecomposants

  1. 01Lecture des messagestexte libre vers lignes de commande
  2. 02Cotationpar fournisseur ; prix connus ou marqués estimés
  3. 03Envoipar référence ; une tentative par clic, refus nommés
  4. 04Lecture des facturesdeux lectures indépendantes, comparées
  5. 05Rapprochementcommande contre facture, ligne à ligne
  6. 06ERP et fournisseurscontenu retenu

Notes

  1. Le total n’invente aucun montant : confirmé, estimé, partiel ou sans prix, c’est écrit.
  2. Un clic, une tentative : aucun renvoi automatique, chaque refus est nommé.
  3. Aucun article deviné ne part chez un fournisseur sans clic humain.

Zones hachurées

Ce que cette planche ne montre pas, et ne montrera pas :

  • Groupe, sites, équipe et fournisseurs
  • Prix et volumes
  • Nom de l’ERP et son schéma

Ce que ça montre

Viser les erreurs qui coûtent : la date, l’aperçu, le total.

Planche suivante, S6Garde-fous pour agents de code

S6

Garde-fous pour agents de code

Une revue de sécurité confiée à des agents, dont neuf analystes en lecture seule, consolidée par script, avec deux portes humaines et un portier qui inspecte chaque commande avant exécution.

Prototype. Version relue le 1er octobre 2026 après trois tours de revue adversariale, avant son premier usage réel.

Planche
S6
Statut
Prototype
Nature
Outil interne
Période
Août à octobre 2026
Rôle
Conception, puis revue adversariale de ses propres garde-fous
Contexte
Startup IA, rôle de CTO
Pile
Python, analyse de la commande shell réelle, sorties JSON validées par schéma, scripts de consolidation
Historique
24 commits versionnés, sous l’identité d’équipe.
Dernière révision
1er oct. 2026
Diffusion
Publique, zones hachurées retenues

SchémaSchéma du portier

Lecture Schéma de tuyauterie et d’instrumentation. La commande circule de l’agent vers le terminal ; la vanne du portier est fermée par défaut et ne s’ouvre que sur un motif autorisé. En bas, la ligne de revue.

Reconstitution à données fictives. Le comportement est celui du système ; les règles, seuils et consignes réels sont retenus.

Analyse

Ce que la planche ne dit pas d’elle-même

Le vrai problème

Le dépôt analysé est une donnée hostile. Et une règle d’interdiction par motif de texte ne voit que des chaînes : elle bloque « git push », pas la même commande écrite autrement.

Le portier doit donc lire la vraie commande, dans un délai borné, et ne jamais laisser passer ce qu’il n’a pas compris.

Décisions

  1. RetenuLe portier ferme par défaut : toute erreur interne devient un blocage.

    ÉcartéLe comportement par défaut de l’outil, où une erreur du crochet laisse passer.

    PourquoiUn portier qui plante ne doit pas ouvrir la porte.

  2. RetenuLe portier est une défense en profondeur ; la barrière primaire est une copie jetable, sans accès distant ni identifiants.

    ÉcartéPrésenter le portier comme une garantie.

    PourquoiIl a des angles morts connus ; la formulation qui promettait plus a été retirée.

  3. RetenuConsolidation et matrice de conformité produites par script, verdict « non vérifié » par défaut.

    ÉcartéUne matrice remplie par le modèle.

    PourquoiUne matrice rédigée par un modèle peut affirmer un contrôle qui n’a pas eu lieu.

Ce qui a cassé

  1. 1er octobre

    La troisième version du portier laissait passer 38 commandes dangereuses sur 42 : réécriture complète. Chaque contournement trouvé est devenu un cas de test avant son correctif.

  2. Une constatation d’une passe remontait dans la passe suivante, avec un risque de fuite entre clients : un marqueur de passe la cantonne.

Limites à ce jour

  • Aucune passe réelle n’est encore versionnée : la version actuelle est relue, pas éprouvée.
  • Angles morts assumés : délai d’analyse dépassé, binaire renommé, code chargé par un programme autorisé.
  • Pour les agents qui ont un terminal, la lecture seule n’est que demandée dans leurs consignes.

Cotesmesures et dénombrements, avec leur mode de mesure

465cas dans la matrice de test du portier : 323 à bloquer, 142 à laisser passercompté dans le dépôt
38 / 42commandes dangereuses qui passaient la troisième versiondocumenté par le projet
10, 8, 4contournements trouvés par trois revues adversariales successives, tous corrigésdocumenté par le projet
0,3 spire temps de décision sur 5 500 commandes aléatoires, mesuré sur la quatrième versiondocumenté par le projet
131règles d’interdiction dans le gabarit de configurationcompté dans le dépôt

Révisions

C1er oct. 2026Portier réécrit, trois revues adversariales, version relue
B11 août 2026Fin de la passe initiale
A10 août 2026Première flotte d’analystes

Nomenclaturecomposants

  1. 01Phase 0barrières avant toute analyse
  2. 02Neuf analysteslecture seule, sortie JSON validée par schéma
  3. 03Trois agents qui écriventtests, correctifs, rapport ; sous les portes humaines
  4. 04Consolidationpar script, sans modèle
  5. 05Portes A et Bdeux validations humaines
  6. 06Portieravant chaque commande, fermé par défaut
  7. 07Règles du portiercontenu retenu

Notes

  1. Toute erreur interne du portier devient un blocage.
  2. Ce qui est appliqué techniquement est séparé de ce qui est seulement demandé au modèle.
  3. Le portier n’est jamais présenté comme une garantie.

Zones hachurées

Ce que cette planche ne montre pas, et ne montrera pas :

  • Règles et motifs du portier
  • Dépôts analysés et leurs failles
  • Témoins de test

Ce que ça montre

Attaquer ses propres garde-fous : chaque contournement trouvé devient un test avant son correctif.

Planche suivante, S7Plan de contrôle d’exploitation

S7

Plan de contrôle d’exploitation

La supervision prévue pour les agents en production : santé sans modèle, retours clients transformés en tickets, correctifs par un agent confiné, déploiement sur double confirmation humaine.

Spécification. Spécification du 27 juillet 2026. Phase 0 faite, phase 1 bloquée sur des droits d’accès ; aucun code de supervision n’est encore écrit.

Planche
S7
Statut
Spécification
Nature
Spécification
Période
Juillet à septembre 2026
Rôle
Conception
Contexte
Startup IA, rôle de CTO
Pile
Prévue : Python asynchrone, SQLite, minuteries système, sessions sans port entrant
Historique
Spécification versionnée, 1 commit.
Dernière révision
10 sept. 2026
Diffusion
Publique, zones hachurées retenues

SchémaCadran de 24 heures

Lecture Un tour de cadran est une journée. Les 288 traits de la couronne sont les contrôles de santé, un toutes les 5 minutes. À l’intérieur, la vie d’un ticket. Comportement spécifié, non implémenté.

Comportement spécifié, non implémenté. Reconstitution à données fictives.

Analyse

Ce que la planche ne dit pas d’elle-même

Le vrai problème

Un seul ingénieur pour une dizaine de produits, dont les consignes sont modifiées hors du dépôt par plusieurs personnes : l’écart entre la machine, le dépôt et la consigne active était invisible.

La spécification arrive après l’incident de silence du 12 juillet ; elle vise à le voir avant l’appelant.

Décisions

  1. RetenuLes droits sont portés par une étiquette de machine.

    ÉcartéUne liste de machines écrite dans le code.

    PourquoiBrancher une machine ne doit toucher ni au code ni aux droits.

  2. RetenuL’agent correcteur tourne sans identifiants ; le superviseur fait le push.

    ÉcartéNon documentée.

    PourquoiUn agent confiné ne doit rien pouvoir publier seul.

  3. RetenuSanté sans modèle ; digest en un seul appel.

    ÉcartéUne session agentique pour la synthèse quotidienne.

    PourquoiLe coût doit rester de l’ordre du centime.

  4. RetenuDéploiement en avance rapide seulement.

    ÉcartéForcer une machine qui a divergé.

    PourquoiUne divergence est un écart à traiter, pas à écraser.

Ce qui a cassé

  1. 26 juillet

    Un secret trouvé en dur dans un produit client, sorti du code ; sa rotation est laissée à l’humain parce que la valeur avait circulé en clair.

  2. Juillet

    Les collages de plusieurs lignes cassaient dans les sessions distantes : remplacés par des scripts d’une ligne.

Limites à ce jour

  • Rien n’est implémenté : la phase 1 attend des droits d’accès.
  • Les protections de branche sont posées mais inertes avec l’offre actuelle : la première porte n’est pas appliquée techniquement.
  • La spécification couvre une seule région, alors que des machines de production tournent ailleurs.

Cotesmesures et dénombrements, avec leur mode de mesure

5 minintervalle des contrôles de santé, sans modèlespécification
07:00heure du digest quotidienspécification
40 tours, 3 USDplafond de l’agent correcteur par ticketspécification
10 minvalidité d’une confirmation de déploiement ; même fenêtre d’activité vérifiée avant de redémarrer une réceptionnistespécification
1correctif actif par dépôtspécification

Révisions

B10 sept. 2026Phase 0 faite, phase 1 bloquée
A27 juil. 2026Spécification, audit des secrets

Nomenclaturecomposants

  1. 01Machines étiquetéesajout par une étiquette et une ligne de registre
  2. 02Superviseursans aucune règle entrante
  3. 03Santécontrôles sans modèle
  4. 04Triageretours clients en JSON strict
  5. 05Agent correcteurconfiné, plafonné en tours et en coût
  6. 06Double portefusion de la demande de modification, puis confirmation exacte
  7. 07Produits et machinescontenu retenu

Notes

  1. Ajouter une machine : une étiquette et une ligne de registre.
  2. Une fusion est un premier feu vert ; la confirmation exacte en est un second.
  3. Une machine divergée est refusée.

Zones hachurées

Ce que cette planche ne montre pas, et ne montrera pas :

  • Produits clients et identifiants de machines
  • Comptes et droits

Ce que ça montre

Poser le moindre privilège avant le code : étiquette de droits, agent sans identifiants, double confirmation.

Planche suivante, S8Exercice technique à correcteur caché

S8

Exercice technique à correcteur caché

Une API fictive à quatre tickets et un correcteur à tests cachés. Le défaut conçu ne se voit pas d’en haut : la synchronisation répond « ok » en n’ayant importé qu’une partie des entrées.

Livré. Livré le 21 septembre 2026 : preuve rouge sur le code livré, puis verte ticket par ticket avec les correctifs de référence. Le passage d’un candidat n’est pas documenté ici.

Planche
S8
Statut
Livré
Nature
Exercice technique
Période
Septembre 2026
Rôle
Conception de l’exercice et du correcteur
Contexte
Startup IA, rôle de CTO
Pile
Python, FastAPI, SQLite plein texte, pytest, amont paginé à pannes injectables
Historique
2 commits versionnés.
Dernière révision
21 sept. 2026
Diffusion
Publique, zones hachurées retenues

SchémaRuban et grille de correction

Lecture En haut, les 137 entrées de l’amont, par pages de 25 : la synchronisation s’arrête à la page 3 et répond « ok ». En bas, chaque case est un cas caché, ticket par ticket : plein pour l’acceptation, contour pour la régression.

Reconstitution à données fictives. Le comportement est celui du système ; les règles, seuils et consignes réels sont retenus.

Analyse

Ce que la planche ne dit pas d’elle-même

Le vrai problème

Le code livré passe ses 43 tests visibles, alors que la synchronisation répond « ok » sur 50 entrées importées sur 137. Il fallait des tests cachés qui ne dépendent pas de la simulation fournie au candidat.

Et prouver, ticket par ticket, que ces tests distinguent un code juste d’un code faux.

Décisions

  1. RetenuLes tests cachés embarquent leur propre implémentation du contrat amont.

    ÉcartéSe fier à la simulation livrée avec l’exercice.

    PourquoiModifier la simulation ne doit ni aider ni pénaliser le candidat.

  2. RetenuUne preuve progressive en cinq exécutions : chaque correctif de référence fait passer son ticket au vert, les autres restent rouges.

    ÉcartéNon documentée.

    PourquoiIsoler chaque ticket montre que chaque test cible son propre défaut.

  3. RetenuLe test rouge est versionné seul, et chaque demande de modification décrit la cause, le correctif, la preuve et l’usage de l’IA, puis se défend à l’oral.

    ÉcartéNon documentée.

    PourquoiLe candidat répond de chaque ligne qu’il soumet.

Ce qui a cassé

  1. 21 septembre

    Aucun incident ; l’installation a été revérifiée sur une machine réinstallée, la précédente n’étant plus vierge.

Limites à ce jour

  • Passage d’un candidat non documenté : seule la branche principale existe.
  • Tests cachés jamais exécutés sous Linux.
  • L’outil de recherche de secrets est optionnel : sans lui, le critère passe avec la mention « non vérifié ».

Cotesmesures et dénombrements, avec leur mode de mesure

53cas cachés : 46 d’acceptation et 7 de régression, répartis 16, 13, 12 et 12 par ticketcompté dans le dépôt
0 / 46cas d’acceptation passés par le code livré ; les 7 cas de régression passentmesuré hors ligne
43 / 43tests visibles verts sur le code livré : le défaut ne se voit pas d’en hautmesuré hors ligne
50 / 137entrées importées par la synchronisation qui répond « ok », panne injectée en page 3spécification
63 / 63tests visibles verts après les correctifs de référencemesuré hors ligne

Révisions

D21 sept. 2026Correcteur versionné
C21 sept. 2026Preuve verte, ticket par ticket
B21 sept. 2026Preuve rouge sur le code livré
A21 sept. 2026Exercice versionné

Nomenclaturecomposants

  1. 01API fictivedossiers, temps, recherche, synchronisation amont
  2. 02Amont paginé25 entrées par page, pannes injectables
  3. 03Tests cachésindépendants de la simulation du candidat
  4. 04Manifestele correcteur échoue si un test caché du kit manque ou change
  5. 05Contrôle des secretsmotifs et fichiers d’environnement toujours vérifiés
  6. 06Solutions de référencecontenu retenu

Notes

  1. Le comportement attendu est prouvé avant d’être demandé : rouge, puis vert.
  2. Un test caché qui manque ou change fait échouer la correction.
  3. Le candidat décrit son usage de l’IA dans chaque demande de modification.

Zones hachurées

Ce que cette planche ne montre pas, et ne montrera pas :

  • Solutions et tests cachés
  • Identité des candidats

Ce que ça montre

Prouver le comportement attendu avant de le demander, et exiger la transparence sur l’usage de l’IA.

Planche suivante, S9Un site où chaque fait a sa source

S9

Un site où chaque fait a sa source

Le site de l’entreprise, statique, sans cookie ni script tiers. Chaque fait affiché vient d’un registre qui exige une source ; un fait nul efface son bloc à la construction.

Construit. Refonte fusionnée début octobre 2026 : registre de faits, en-têtes de sécurité, contrôles de construction. Mise en ligne non vérifiée à ce jour.

Planche
S9
Statut
Construit
Nature
Site d’entreprise
Période
Août à octobre 2026
Rôle
Refonte, registre des faits, contrôles de construction
Contexte
Startup IA, rôle de CTO
Pile
Générateur statique, politique de sécurité stricte, contrôles en intégration continue, captures automatisées
Historique
35 commits, dont 25 à mon nom.
Dernière révision
2 oct. 2026
Diffusion
Publique, zones hachurées retenues

SchémaÉpure à renvois

Lecture La page en épure et le registre des faits. Chaque bloc renvoie par un repère numéroté à une ligne du registre. Un fait sans source efface son bloc et la page se referme.

Reconstitution à données fictives. Le comportement est celui du système ; les règles, seuils et consignes réels sont retenus.

Analyse

Ce que la planche ne dit pas d’elle-même

Le vrai problème

Pour une société qui vend de la conformité, le site devait appliquer la même règle de preuve que la production, alors que le message lui-même évoluait encore.

Le relevé de l’ancien site a compté 94 affirmations, toutes à rattacher à une source avant de rester en ligne.

Décisions

  1. RetenuChaque fait est une valeur plus une source ; un fait nul efface son bloc.

    ÉcartéLaisser un gabarit vide ou un espace réservé.

    PourquoiUn bloc vide affiche encore une promesse.

  2. Retenu« Non sourcé » est un état distinct de « faux ».

    ÉcartéQualifier de faux tout ce qui manque à un annuaire public.

    PourquoiUn annuaire peut être en retard sur la réalité.

  3. RetenuSite statique sans script en ligne, politique de sécurité stricte.

    ÉcartéUne application rendue dans le navigateur.

    PourquoiLa page doit se lire sans JavaScript.

Ce qui a cassé

  1. 31 août

    Première mesure des mots lisibles sans JavaScript fausse ; refaite et corrigée dans le dossier de revue.

  2. 31 août

    Le registre a raté un pilote en cours dans la restauration : un faux négatif, corrigé quand le secteur est revenu en avant.

Limites à ce jour

  • Mise en ligne non vérifiée : elle dépend d’une branche non fusionnée.
  • Aucun script ne contrôle la validité des sources : elle se juge en revue.
  • La politique de sécurité tolère encore les styles en ligne.

Cotesmesures et dénombrements, avec leur mode de mesure

94affirmations relevées sur l’ancien site et passées au registredocumenté par le projet
8 → 422mots lisibles sans JavaScript sur l’accueil, mesurés le 31 aoûtmesuré hors ligne
17 / 17couples de contraste conformes, calculés sur les couleurs du thème et contrôlés en intégration continuemesuré hors ligne

Révisions

C2 oct. 2026Message mis à jour par la direction
B1er oct. 2026Refonte fusionnée, contrastes contrôlés
A31 août 2026Relevé de l’ancien site, registre des faits

Nomenclaturecomposants

  1. 01Registre de faitschaque fait : une valeur, une source
  2. 02Générateur statiqueaucun script en ligne
  3. 03Règle de constructionun fait nul masque son bloc, sans espace réservé
  4. 04En-têtes de sécuritépolitique stricte, styles en ligne encore tolérés
  5. 05Contrôles de l’artefacten intégration continue
  6. 06Démos animéesdonnées fictives seulement

Notes

  1. Source ou suppression, appliqué par la construction.
  2. « Non sourcé » et « faux » sont deux états distincts.
  3. Un cas de démonstration n’est jamais présenté comme en production.

Zones hachurées

Ce que cette planche ne montre pas, et ne montrera pas :

  • Sous-domaines et captures clients
  • Fichiers de déploiement

Ce que ça montre

Rendre la règle de preuve mécanique, et consigner les erreurs de mesure de sa propre chaîne.

Planche suivante, C1Plateforme d’analytics locale

C1

Plateforme d’analytics locale

Pour un réseau national de distribution : déposer un fichier de ventes de 2,6 Go et obtenir l’analyse du réseau, des simulations à 36 mois et des interprétations rédigées. Les chiffres sont calculés par des moteurs déterministes ; le modèle ne fait que les formuler.

Livré. Pilote validé sur six magasins le 9 juin 2026, version nationale livrée le 26 juin avec des chiffres marqués indicatifs, non validés. L’usage après livraison n’est pas documenté.

Planche
C1
Statut
Livré
Nature
Mission de conseil
Période
Avril à juin 2026
Rôle
Conception et développement de bout en bout, de l’ingestion à l’interface
Contexte
Conseil, Ascend Partners
Pile
Python, DuckDB, pandas, simulation multi-agents Mesa, FastAPI, React, TypeScript
Historique
Versionné dans les dépôts de la mission.
Dernière révision
26 juin 2026
Diffusion
Publique, zones hachurées retenues

SchémaFaisceau de réplications

Lecture Chaque trait fin est une réplication de la simulation sur 36 mois ; le trait fort est la moyenne. Le second panneau montre, selon le scénario, la convergence de la moyenne, l’intervalle sur l’écart entre deux scénarios ou le contrôle d’une réponse. Données fictives.

Reconstitution à données fictives. Le comportement est celui du système ; les règles, seuils et consignes réels sont retenus.

Analyse

Ce que la planche ne dit pas d’elle-même

Le vrai problème

Le fichier de ventes pesait 2,6 Go et une colonne critique arrivait vide à 84 % ; le chiffre phare dépendait justement d’elle.

Et une interprétation rédigée peut énoncer un chiffre juste au mauvais périmètre : pendant les tests, une réponse sur un magasin a donné la valeur du réseau entier.

Décisions

  1. RetenuLe chiffre phare reste bloqué tant que la colonne de gamme est couverte à moins de 90 % ; la gamme n’est jamais devinée.

    ÉcartéImputer les valeurs manquantes.

    PourquoiMesurer le trou a permis au client de reconstruire la colonne à la source.

  2. RetenuL’intervalle de confiance est calculé sur l’écart apparié, réplication par réplication.

    ÉcartéAdditionner les marges des deux scénarios.

    PourquoiL’addition gonflait l’intervalle d’un ordre de grandeur.

  3. RetenuChaque interprétation passe un contrôle PASS, WARN ou FAIL ; en échec, deux essais au plus, puis un texte déterministe.

    ÉcartéRelancer jusqu’à obtenir un PASS.

    PourquoiLa latence, et une relance en boucle finit par passer par hasard.

  4. RetenuGarder le chiffre défendable.

    ÉcartéAjuster la formule vers le chiffre espéré.

    PourquoiLe chiffre devait tenir devant un comité de direction.

Ce qui a cassé

  1. 13 avril

    Un écart de scénario 28 fois trop fort, puis une cible sur trois ans lue comme annuelle : formules recalibrées.

  2. 6 mai

    Recalcul indépendant de 30 chiffres présentés : 22 conformes et 6 en échec au premier passage, puis 30 sur 30.

  3. 7 mai

    Un audit externe trouve des signes inversés sur trois scénarios ; corrigés.

  4. Juin

    Une valeur nationale servie sous l’étiquette d’un centre : ajout d’une garde de granularité.

Limites à ce jour

  • Les chiffres nationaux sont livrés comme indicatifs, non validés.
  • Plus de la moitié des regroupements régionaux sortent d’une marge de 10 % : l’affichage est plafonné au niveau que la statistique certifie.
  • Les élasticités utilisées n’ont pas de référence académique vérifiée.
  • La rédaction des interprétations appelle un modèle ; sans lui, le texte déterministe prend le relais.

Terrains

ClientCe qui tourneStatut daté
Réseau national de distribution, piloteSix magasins, environ 80 000 lignesPilote validé le 9 juin 2026
Réseau national de distribution, échelle nationaleFichier de 2,6 Go, ingestion hors mémoireLivré le 26 juin 2026, chiffres indicatifs

Cotesmesures et dénombrements, avec leur mode de mesure

2,6 Gofichier de ventes ingéré en 5,3 s, avec un pic mémoire de 3,2 Gomesuré hors ligne
27 → 2 minsimulation complète à 10 réplications, après inversion de l’échantillonnage ; résultats reproduits au centimemesuré hors ligne
40réplications à partir desquelles la moyenne se stabilise ; l’intervalle continue de se resserrer à 160mesuré hors ligne
30 / 30chiffres présentés recalculés indépendamment, conformes après correctionmesuré hors ligne
2 000agents clients dans la configuration de référencecompté dans le dépôt

Révisions

E26 juin 2026Version nationale livrée
D9 juin 2026Pilote validé sur six magasins
C7 mai 2026Audit externe : signes corrigés
B6 mai 2026Recalcul indépendant des chiffres présentés
A13 avr. 2026Écarts de scénario recalibrés

Nomenclaturecomposants

  1. 01Ingestion hors mémoirelecture en flux depuis le disque, contrat de schéma à 22 colonnes
  2. 02Moteurs déterministeschaque chiffre calculé et figé avant affichage
  3. 03Simulation multi-agents36 mois, réplications, intervalle sur l’écart apparié
  4. 04Contrôle PASS, WARN, FAILsur chaque interprétation rédigée
  5. 05Garde de granularitéun chiffre ne change pas de périmètre
  6. 06Données et constantes du clientcontenu retenu

Notes

  1. Le modèle formule ; il ne calcule jamais.
  2. Un chiffre affiché correspond à un champ calculé et figé.
  3. Une valeur manquante bloque le chiffre qui en dépend.

Zones hachurées

Ce que cette planche ne montre pas, et ne montrera pas :

  • Réseau, enseigne et magasins
  • Fichier de ventes et constantes métier
  • Scénarios et résultats du client

Sources

  • 2,6 Go en 5,3 smessage de commit du dépôt de mission
  • 30 sur 30historique du dépôt
  • 40 réplications, 27 → 2 minconstantes documentées du dépôt
  • 84 %dictionnaire de données du dépôt

Ce que ça montre

Porter un outil de décision chiffré du pilote au national, en refusant d’afficher ce que la statistique ne certifie pas.

Planche suivante, C2GEO Audit

C2

GEO Audit

Mesurer ce que les moteurs génératifs répondent quand on les interroge sur un secteur, sans leur souffler la marque. Un questionnaire, cinq moteurs, des réponses lues mot pour mot.

Livré. Premier audit réel le 29 mai 2026 pour une enseigne nationale ; rapport validé le 1er juin.

Planche
C2
Statut
Livré
Nature
Outil de mission
Période
Mai à juin 2026
Rôle
Conception de la mesure et de l’outil
Contexte
Conseil, Ascend Partners
Pile
Python, React, verrou par audit, coût suivi par appel
Historique
Versionné.
Dernière révision
8 juin 2026
Diffusion
Publique, zones hachurées retenues

SchémaRose des moteurs

Lecture Cinq branches, une par moteur ; quatre anneaux, un par catégorie de questions, découpés en quatre questions. Chaque case est un croisement ; le détail A déroule une branche. Données fictives.

Reconstitution à données fictives. Le comportement est celui du système ; les règles, seuils et consignes réels sont retenus.

Analyse

Ce que la planche ne dit pas d’elle-même

Le vrai problème

Une marque faite de mots courants se retrouve à l’intérieur d’autres mots : compter les mentions par simple recherche de texte surestime sa présence.

La découverte n’a de sens que si la question ne contient pas la marque ; sinon, le moteur répète ce qu’on lui a soufflé.

Décisions

  1. RetenuCorrespondance sur des mots entiers.

    ÉcartéLa recherche de sous-chaînes.

    PourquoiUne sous-chaîne compte des mentions qui n’en sont pas.

  2. RetenuConversations neutres et conversations de marque séparées ; neutralité imposée par le serveur, question régénérée si la marque fuit.

    ÉcartéLaisser le modèle formuler les questions librement.

    PourquoiC’est la condition de validité de la découverte.

  3. RetenuUn collage ambigu est rendu à l’opérateur pour découpage.

    ÉcartéDeviner le découpage.

    PourquoiUn collage à recadrer coûte moins cher qu’un score faux et silencieux.

  4. RetenuLes réponses obtenues par un outil de développement sortent du score.

    ÉcartéLes garder comme approximation du produit grand public.

    PourquoiElles ne sont pas comparables.

Ce qui a cassé

  1. Une recherche web gardait un canal ouvert et les recommandations tournaient en boucle : toute l’arborescence de processus est désormais arrêtée.

  2. 29 mai

    Un verrou de stockage rendait les audits illisibles : les lectures renvoient désormais une erreur explicite.

Limites à ce jour

  • Les réponses des moteurs sont collées par l’opérateur : la mesure est semi-manuelle.
  • Une réponse par croisement : la variance d’un moteur d’une fois sur l’autre n’est pas mesurée.
  • Comptage et analyse rédigée donnent des niveaux différents sur un même audit : le score dépend du mode de lecture.

Terrains

ClientCe qui tourneStatut daté
Enseigne nationale de distributionQuatre catégories, quatre questions, cinq moteurs : 80 croisementsRapport validé le 1er juin 2026

Cotesmesures et dénombrements, avec leur mode de mesure

5 × 4moteurs et catégories du questionnaire de basecompté dans le dépôt
80croisements remplis lors du premier audit réeldocumenté par le projet
58fonctions de testcompté dans le dépôt

Révisions

C8 juin 2026Import de questionnaires depuis une note de cadrage
B1er juin 2026Rapport validé
A29 mai 2026Premier audit réel

Nomenclaturecomposants

  1. 01Questionnairenotoriété, découverte sectorielle, intention d’achat, valeurs et alternatives
  2. 02Conversations neutressans la marque, neutralité imposée par le serveur
  3. 03Lecture des réponsesmots entiers ; découpage refusé s’il est ambigu
  4. 04Verrou par auditun seul processus écrit un audit
  5. 05Suivi du coûtpar appel
  6. 06Réponses et scores du clientcontenu retenu

Notes

  1. La question de découverte ne contient jamais la marque.
  2. Un découpage ambigu est rendu à l’opérateur.
  3. Une réponse non comparable sort du score.

Zones hachurées

Ce que cette planche ne montre pas, et ne montrera pas :

  • Enseigne et concurrents
  • Réponses des moteurs et scores

Sources

  • 80 croisementsfichier d’audit du dépôt
  • 58 fonctions de testcomptage du dépôt
  • Dateshistorique du dépôt

Ce que ça montre

Concevoir une mesure sur un sujet neuf, avec des garde-fous de mesure écrits.

Planche suivante, C3Audit d’un moteur de scoring hérité

C3

Audit d’un moteur de scoring hérité

Des scores de résilience avaient chuté sur plusieurs actifs sans explication. Avant de chercher la cause, reproduire au centième les trois versions successives du moteur de scoring, écrit en VBA.

Livré. Mission de conseil menée en 2026 pour une grande institution. Le code est resté chez le client : les chiffres de cette planche sont déclarés, sans dépôt consultable.

Planche
C3
Statut
Livré
Nature
Mission de conseil
Période
2026
Rôle
Reconstruction des moteurs en Python, harnais de tests, restitution
Contexte
Conseil, Ascend Partners
Pile
Python, harnais de tests, lecture de code VBA
Historique
Aucun dépôt consultable : le travail est resté chez le client.
Diffusion
Publique, zones hachurées retenues

SchémaDiagramme des résidus

Lecture Chaque colonne est un actif fictif ; chaque marque, l’écart entre le score reconstruit et le score d’origine à une passe. La bande est l’écart maximal admis d’un centième. Les passes successives ramènent les points dans la bande.

Reconstitution à données fictives. Le comportement est celui du système ; les règles, seuils et consignes réels sont retenus.

Analyse

Ce que la planche ne dit pas d’elle-même

Le vrai problème

Expliquer une chute de scores alors que la méthode de calcul elle-même était contestée en interne. Tant que la chute n’était pas reproduite, toute explication restait une opinion.

Décisions

  1. RetenuReconstruire les trois moteurs successifs jusqu’à retrouver chaque score au centième, puis seulement chercher la cause.

    ÉcartéChercher la cause directement dans le code hérité.

    PourquoiSans reproduction exacte, une cause trouvée ne se démontre pas.

  2. RetenuUn harnais de tests qui fige chaque écart.

    ÉcartéNon documentée.

    PourquoiChaque hypothèse de cause devient vérifiable.

Résultat

Cause trouvée : une requalification des réponses par coefficient, combinée à un passage à la moyenne géométrique au niveau des piliers. Restituée avec une note de gouvernance pour aligner les équipes sur la méthode.

Ce qui a cassé

  1. Aucun incident documenté.

Limites à ce jour

  • Aucun dépôt consultable : la planche repose sur la restitution de la mission.
  • La décision prise ensuite par le client n’est pas documentée ici.

Terrains

ClientCe qui tourneStatut daté
Une grande institutionReconstruction et audit d’un moteur de scoringMission livrée en 2026

Cotesmesures et dénombrements, avec leur mode de mesure

3versions successives du moteur hérité, reconstruitesdéclaré, sans dépôt consultable
0,01écart maximal admis entre un score reconstruit et le score d’originedéclaré, sans dépôt consultable
304tests du harnais de vérificationdéclaré, sans dépôt consultable

Nomenclaturecomposants

  1. 01Moteur héritétrois versions successives, en VBA
  2. 02Reconstructionun moteur Python par version
  3. 03Harnaischaque score comparé au centième
  4. 04Données et pondérations du clientcontenu retenu

Notes

  1. Reproduire d’abord, conclure ensuite.
  2. Un écart non expliqué reste un écart ouvert.

Zones hachurées

Ce que cette planche ne montre pas, et ne montrera pas :

  • Client, actifs et scores
  • Méthode de scoring et pondérations

Sources

  • Tous les chiffresrestitution de la mission ; déclarés, le code est resté chez le client

Ce que ça montre

Trancher un désaccord de méthode par la preuve, en reproduisant avant de conclure.

Planche suivante, C4Chaîne de présentations

C4

Chaîne de présentations

Transformer des notes de consultants en présentations de comité, en séparant la charte de chaque client des règles de composition, et sans réécrire un mot du consultant.

Prototype. Conçu en mai 2026 ; jamais éprouvé de bout en bout sur un vrai deck.

Planche
C4
Statut
Prototype
Nature
Prototype d’outil
Période
Mai 2026
Rôle
Conception
Contexte
Conseil, Ascend Partners
Pile
Composition HTML, rendu vers le format de présentation, planche de miniatures, skills d’agent
Historique
Versionné, un commit.
Dernière révision
19 mai 2026
Diffusion
Publique, zones hachurées retenues

SchémaChemin de fer

Lecture La charte extraite, la note du consultant, puis le chemin de fer du deck, page par page, comme en imprimerie. Les repères numérotés relient chaque idée de la note à sa page. Données fictives.

Reconstitution à données fictives. Le comportement est celui du système ; les règles, seuils et consignes réels sont retenus.

Analyse

Ce que la planche ne dit pas d’elle-même

Le vrai problème

Chaque présentation part chez un client dont la charte doit être respectée, et le texte du consultant ne doit pas bouger : la machine compose, elle n’écrit pas.

Décisions

  1. RetenuRègles de composition codées une fois ; charte extraite du deck de chaque client.

    ÉcartéNon documentée.

    PourquoiLe critère de tri : si la valeur change d’un client à l’autre, elle va dans la charte.

  2. RetenuLe texte du consultant n’est jamais réécrit.

    ÉcartéLe réécrire pour l’améliorer.

    PourquoiLe consultant choisit ses mots.

  3. RetenuContrôle sur une planche de miniatures avant toute livraison.

    ÉcartéNon documentée.

    PourquoiRepérer d’un coup d’œil un texte coupé ou un chevauchement.

Ce qui a cassé

  1. Aucun incident : la chaîne n’a pas tourné de bout en bout.

Limites à ce jour

  • Jamais validée sur un vrai deck.
  • Un texte à plusieurs styles perd sa mise en forme au rendu.
  • Le logo n’est pas extrait de la charte.
  • Un seul système d’exploitation pris en charge.

Cotesmesures et dénombrements, avec leur mode de mesure

3skills enchaînés : extraction de la charte, composition, renducompté dans le dépôt
13dispositifs visuels de compositioncompté dans le dépôt

Révisions

A19 mai 2026Squelette de la chaîne

Nomenclaturecomposants

  1. 01Charteextraite du deck du client : couleurs, typographies, gabarits
  2. 02Règles de compositioncommunes à tous les clients
  3. 03Compositionchaque page choisie parmi des dispositifs
  4. 04Rendu et miniaturesplanche de contrôle avant livraison

Notes

  1. Le texte du consultant est intouchable.
  2. La charte varie d’un client à l’autre ; les règles restent.

Zones hachurées

Ce que cette planche ne montre pas, et ne montrera pas :

  • Chartes et decks des clients

Sources

  • 3 skills, 13 dispositifsdocumentation du dépôt
  • Statutnotes d’itération du dépôt

Ce que ça montre

Séparer ce qui varie de ce qui reste, et dire qu’un outil n’est pas encore éprouvé.

Planche suivante, C5Agents de recherche pour une équipe

C5

Agents de recherche pour une équipe

Un kit d’installation, des agents et des skills pour faire travailler une équipe de conseil avec des agents de code : benchmark de solutions, fiches d’éditeurs, audit de grilles. L’orchestration a été repensée après une livraison réelle.

Livré. Kit diffusé fin mars 2026 ; benchmark livré et audité en avril pour un séminaire de direction ; adopté par une consultante pour une mission.

Planche
C5
Statut
Livré
Nature
Outil d’équipe
Période
Mars à mai 2026
Rôle
Conception des agents, des skills et du kit ; correctifs après livraison
Contexte
Conseil, Ascend Partners
Pile
Agents et skills de code, crochets de sécurité, tests, intégration continue
Historique
Versionné ; une partie des correctifs porte l’identité d’une collègue.
Dernière révision
28 mai 2026
Diffusion
Publique, zones hachurées retenues

SchémaBaie de brassage

Lecture En haut, les sorties de la session principale, une par phase ; en bas, les agents et les skills. Chaque cordon est un lancement : seule la session principale branche un cordon. En dessous, les crochets qui bloquent certaines commandes.

Reconstitution à données fictives. Le comportement est celui du système ; les règles, seuils et consignes réels sont retenus.

Analyse

Ce que la planche ne dit pas d’elle-même

Le vrai problème

Passer d’un usage individuel à une équipe a buté sur une limite de l’outil : un sous-agent ne peut pas lancer d’autres sous-agents. L’orchestration en cascade prévue ne fonctionnait pas, et on ne l’a vu qu’après une livraison réelle.

Décisions

  1. RetenuLa session principale orchestre et lance les agents en parallèle ; l’agent chef ne fait plus que le cadrage.

    ÉcartéUne cascade d’agents.

    PourquoiLimite native de l’outil.

  2. RetenuDeux modes d’installation : minimal pour les profils non techniques, complet pour les autres.

    ÉcartéUn paquet unique.

    PourquoiLes profils non techniques n’ont pas besoin de tout installer.

  3. RetenuDes crochets bloquent les commandes destructrices, la lecture de fichiers sensibles et les scripts téléchargés puis exécutés.

    ÉcartéNon documentée.

    PourquoiJamais de données client réelles dans les consignes.

Ce qui a cassé

  1. 20 avril

    L’audit qui suit la première livraison relève des problèmes bloquants : orchestration revue, rendu de document corrigé.

  2. Un chiffre incohérent sur un éditeur conduit à écrire un contrôleur de cohérence.

Limites à ce jour

  • Adoption documentée pour une seule consultante.
  • Les serveurs d’outils sont listés, rarement installés par le kit.
  • Le kit embarque aussi des paquets de skills tiers.

Terrains

ClientCe qui tourneStatut daté
Cabinet de conseilKit d’installation, crochets, sous-agentsDiffusé fin mars 2026
Groupe industriel, séminaire de directionBenchmark multi-agents, tableur et note de synthèseLivré et audité en avril 2026
Groupe mutualiste de santéAudit d’une grille de notation, six détecteurs de biaisMai 2026

Cotesmesures et dénombrements, avec leur mode de mesure

6skills écrits en propre, pour 5 à 7 agents selon la versioncompté dans le dépôt
58tests verts de la pile de benchmarkdocumenté par le projet
139tests passés en intégration continue sur l’auditeur de grillescompté dans le dépôt
10 en 78 minéditeurs traités sur un cas fictif d’administrationdocumenté par le projet

Révisions

D28 mai 2026Auditeur de grilles
C20 avr. 2026Audit après livraison, orchestration revue
B16 avr. 2026Cas fictif : 10 éditeurs en 78 minutes
A26 mars 2026Kit d’installation

Nomenclaturecomposants

  1. 01Session principaleorchestre et lance les agents en parallèle
  2. 02Agentsdécouverte, investigation, critique, contradiction
  3. 03Skillsvérification des faits, crédibilité des sources, notation pondérée
  4. 04Crochetscommandes destructrices, fichiers sensibles
  5. 05Gabarit de missionun fichier d’instructions par mission

Notes

  1. Une limite de l’outil se traite dans l’architecture.
  2. Pas de données client réelles dans les consignes.

Zones hachurées

Ce que cette planche ne montre pas, et ne montrera pas :

  • Clients et livrables
  • Grilles de notation

Sources

  • 6 skills, 5 à 7 agentscomptage des dépôts
  • 58 et 139 testsjournal des versions, intégration continue
  • 10 éditeurs en 78 minmessage de commit

Ce que ça montre

Faire passer un outillage d’agents d’un poste à une équipe, et le corriger après une livraison réelle.

Planche suivante, P1Pré-revue de conformité

P1

Pré-revue de conformité

Avant qu’un support marketing parte à la conformité d’un courtier en valeurs américain, une pré-revue : passages surlignés, mentions manquantes, corrections écrites dans le PDF. Seuls les points certains vont au banquier.

Prototype. Construit pour un hackathon, du 10 au 12 septembre 2026. Résultat du hackathon et déploiement non documentés.

Planche
P1
Statut
Prototype
Nature
Hackathon
Période
Septembre 2026
Rôle
Conçu, construit et évalué
Contexte
Projets personnels et indépendants
Pile
Python, lecture et mise à jour incrémentale de PDF sans bibliothèque, modèle sans outils en un seul tour, chaîne d’empreintes SHA-256
Historique
Versionné, 7 commits.
Dernière révision
12 sept. 2026
Diffusion
Publique, zones hachurées retenues

SchémaÉpreuve corrigée

Lecture Une page de support marketing fictive, annotée comme une épreuve d’imprimerie : chaque marque en marge renvoie à un passage du document. Selon le scénario, la fiche d’une règle et ses verdicts, ou la chaîne des verdicts liés par empreinte.

Reconstitution à données fictives. Le comportement est celui du système ; les règles, seuils et consignes réels sont retenus.

Analyse

Ce que la planche ne dit pas d’elle-même

Le vrai problème

Le moteur de règles de la version précédente produisait des points qu’un reviewer ne pouvait pas envoyer, et les modèles varient d’une exécution à l’autre. Il fallait savoir ce qu’on pouvait affirmer.

Décisions

  1. RetenuSeuls les points affirmés vont au banquier ; le reste part au reviewer.

    ÉcartéTout afficher.

    PourquoiNe jamais lui dire ce que la machine ne sait pas prouver.

  2. RetenuUne vérité terrain écrite à l’avance, et le moteur précédent exécuté sans modification sur le même corpus.

    ÉcartéNon documentée.

    PourquoiComparer à l’existant, sur des erreurs connues.

  3. RetenuLe texte des reviewers est une donnée : le modèle tourne sans outils, en un seul tour, sans session.

    ÉcartéLaisser un commentaire influencer les règles.

    PourquoiFermer la porte à l’injection de consignes.

  4. RetenuCorrections écrites par mise à jour incrémentale du PDF.

    ÉcartéRéécrire le PDF.

    PourquoiLe document d’origine reste intact sous la correction.

Ce qui a cassé

  1. Hackathon

    Au premier passage complet, trois points plantés sont manqués sur un document, dont un graphique vectoriel lu comme du texte. Sept règles corrigées avant le second passage.

Limites à ce jour

  • Le corpus de test est écrit par l’auteur des règles : c’est un banc de régression, pas un benchmark.
  • Les chiffres viennent du second passage, après calibration.
  • La connexion identifie l’utilisateur sans l’authentifier.
  • La correction est une surcouche : le texte d’origine reste dessous.

Terrains

ClientCe qui tourneStatut daté
Courtier en valeurs américain, hackathonCalibration sur un deck réel et la fiche d’un reviewerPrototype, septembre 2026

Cotesmesures et dénombrements, avec leur mode de mesure

71 → 100 %rappel sur 7 documents à erreurs plantées, contre le moteur précédent ; second passagemesuré hors ligne
31 → 4 %faux positifs sur le même corpusmesuré hors ligne
60 % sur 5rejets qui rétrogradent une règle ; 80 % sur 8 l’écartentcompté dans le dépôt
0,32 à 0,82 $coût par document, pour 2 à 5 minutes de traitementmesuré hors ligne

Révisions

B12 sept. 2026Dernier commit du hackathon
A10 sept. 2026Version 0.2 du moteur

Nomenclaturecomposants

  1. 01Passe déterministementions obligatoires cherchées mot pour mot
  2. 02Deux passes de modèlecartographie du document, rédaction des constats
  3. 03Citationschaque constat cite un passage retrouvé dans le PDF
  4. 04Correctionsmise à jour incrémentale, document relu après correction
  5. 05Verdictschaque décision enregistrée et chaînée par empreinte
  6. 06Procédures internes du clientcontenu retenu

Notes

  1. Une citation introuvable rétrograde le constat.
  2. Un désaccord entre reviewers est signalé, jamais tranché par la machine.
  3. L’envoi reste bloqué tant que les corrections ne sont pas revérifiées.

Zones hachurées

Ce que cette planche ne montre pas, et ne montrera pas :

  • Marque et procédures du client
  • Decks réels

Sources

  • Rappel et faux positifsrapport de simulations du dépôt
  • Seuils de rétrogradationdocument d’architecture du dépôt
  • Coûtrapport de simulations du dépôt
  • Dateshistorique git

Ce que ça montre

Transformer une règle de conformité en produit évalué contre une vérité terrain et contre l’existant, en publiant ses propres limites.

Planche suivante, P2Site d’un concessionnaire nautique

P2

Site d’un concessionnaire nautique

Le stock d’un concessionnaire se met à jour en déposant la fiche PDF exportée de son outil métier. Un lecteur PDF écrit sans dépendance en tire l’annonce, qui arrive en demande de modification à relire.

En production. En ligne depuis le 17 août 2026 pour une entreprise familiale ; stock mis à jour le 19 août et le 3 septembre.

Planche
P2
Statut
En production
Nature
Projet indépendant
Période
Août à septembre 2026
Rôle
Conçu, construit, mis en production et audité
Contexte
Projets personnels et indépendants
Pile
Next.js statique, lecteur PDF maison, intégration continue, lien magique
Historique
Versionné.
Dernière révision
3 sept. 2026
Diffusion
Publique, zones hachurées retenues

SchémaCalibres entre et n’entre pas

Lecture Un fichier passe trois calibres avant d’être lu : taille, pages, taille décompressée. Il entre ou il n’entre pas ; rien n’est forcé. Ensuite, les champs tirés de la fiche. Données fictives.

Reconstitution à données fictives. Le comportement est celui du système ; les règles, seuils et consignes réels sont retenus.

Analyse

Ce que la planche ne dit pas d’elle-même

Le vrai problème

Ingérer l’export PDF d’un outil tiers sans base de données, sans mot de passe et sans rien deviner. Un fichier reçu contenait deux bateaux : l’annonce produite mélangeait leurs photos.

Et une limite de débit gardée en mémoire ne tient pas sur une plateforme sans serveur.

Décisions

  1. RetenuLa fiche PDF que l’équipe exporte déjà.

    ÉcartéLe flux XML payant d’une place de marché.

    PourquoiLa négociation tarifaire n’a pas abouti.

  2. RetenuUn lecteur PDF maison, borné : 30 Mo, 40 pages, 64 Mo décompressés.

    ÉcartéUne bibliothèque générique.

    PourquoiAucune exception ne doit sortir d’un PDF hostile.

  3. RetenuUn champ absent devient « à confirmer » ; la machine ne départage jamais deux annonces du même modèle et ne remplace jamais une photo par une moins bonne.

    ÉcartéNon documentée.

    PourquoiRien n’est deviné.

  4. RetenuUn lien magique valable 15 minutes, révocable en changeant le secret.

    ÉcartéUne base de sessions.

    PourquoiPas de base de données à maintenir.

Ce qui a cassé

  1. 17 août

    Audit du jour de mise en ligne : 14 requêtes consécutives sans limitation de débit, et une tâche planifiée qui tournait sur une branche par défaut en retard de 42 commits. Branche corrigée, actions épinglées par empreinte.

  2. 17 août

    Premier jet de l’espace de gestion : les codes de réponse permettaient de deviner les adresses des administrateurs. Corrigé.

  3. 19 août

    Un PDF contenait deux bateaux : les fiches sont désormais découpées bateau par bateau.

Limites à ce jour

  • La limite de débit reste en mémoire ; les règles de pare-feu prévues ne sont pas posées.
  • Pas de protection de branche.
  • L’autonomie du client n’est pas prouvée : les deux mises à jour de stock ont été faites à sa demande.

Terrains

ClientCe qui tourneStatut daté
Concessionnaire de bateaux, entreprise familialeSite statique, stock mis à jour par fiche PDFEn production depuis le 17 août 2026

Cotesmesures et dénombrements, avec leur mode de mesure

93tests du site, dont 50 sur la chaîne PDFcompté dans le dépôt
632photos reprises de l’ancien site, aucune perduedocumenté par le projet
93 et 99Lighthouse en performance, accueil et annonce ; mesure locale du 14 août, avant mise en lignemesuré hors ligne
52pages, et 48 redirections depuis l’ancien sitedocumenté par le projet

Révisions

E3 sept. 2026Mise à jour du stock
D19 août 2026Fiches découpées bateau par bateau
C17 août 2026Mise en ligne, audit de sécurité
B15 août 2026Direction artistique arrêtée, scène 3D retirée
A14 août 2026Mesures de performance

Nomenclaturecomposants

  1. 01Lecteur PDFsans dépendance ; refuse ce qu’il ne connaît pas
  2. 02Ingestiondépôt d’une fiche, tests, demande de modification avec rapport
  3. 03Espace de gestionlien magique de 15 minutes ; aucune route n’écrit
  4. 04Photosjamais remplacées par une moins bonne

Notes

  1. Un champ absent est marqué « à confirmer ».
  2. Chaque geste de gestion revient sous forme de proposition à relire.

Zones hachurées

Ce que cette planche ne montre pas, et ne montrera pas :

  • Entreprise, stock et prix
  • Secrets de déploiement

Sources

  • 17 août, 14 requêtesrapport d’audit de sécurité du dépôt
  • Bornes du lecteurcode du lecteur PDF
  • 93 et 99, 632 photos, 52 pagesrapport global du dépôt
  • 93 testscomptage des cas de test

Ce que ça montre

Mener un projet réel jusqu’en production, avec une ingestion qui refuse de deviner et un audit qui mesure ses propres failles.

Planche suivante, P3Arbitrage de fusions-acquisitions

P3

Arbitrage de fusions-acquisitions

Lire les annonces d’offres publiques de trois régulateurs européens, chacun dans son format, pour en tirer le prix offert et noter l’opportunité. Aucun ordre n’a été passé : le projet s’est arrêté sur ses propres mesures.

Prototype. Construit en mai et juin 2026, par phases validées une à une ; en sommeil depuis.

Planche
P3
Statut
Prototype
Nature
Projet personnel
Période
Mai à juin 2026
Rôle
Conçu et construit
Contexte
Projets personnels et indépendants
Pile
Python, PostgreSQL et migrations versionnées, un analyseur par juridiction, modèle de notation
Historique
Versionné.
Dernière révision
25 mai 2026
Diffusion
Publique, zones hachurées retenues

SchémaLecture d’un avis et courbe ROC

Lecture Un avis d’offre fictif, en allemand comme à la source, annoté en français : le lecteur cherche la clause en espèces, car le premier montant est la valeur nominale. La courbe ROC situe le modèle de notation par rapport à sa cible.

Reconstitution à données fictives. Le comportement est celui du système ; les règles, seuils et consignes réels sont retenus.

Analyse

Ce que la planche ne dit pas d’elle-même

Le vrai problème

Trois régulateurs, trois formats, trois protections d’accès différentes. Dans les avis allemands, la valeur nominale de l’action précède le prix offert : le premier montant lu n’est pas le bon.

Et peu d’échecs étiquetés pour entraîner le modèle : 7 sur 128 cas.

Décisions

  1. RetenuDes phases débloquées une par une, sur validation explicite.

    ÉcartéNon documentée.

    PourquoiNe pas construire sur une phase non validée.

  2. RetenuLe prix offert est lu sur la clause en espèces ; une offre mixte reste vide, avec un indicateur.

    ÉcartéPrendre le premier montant en euros.

    PourquoiLa valeur nominale le précède dans les avis allemands.

  3. RetenuLa décision est séparée du courtier, sur des prix publics.

    ÉcartéUn abonnement lié à un compte réel approvisionné.

    PourquoiTester la décision sans engager d’argent.

  4. RetenuPas de seconde version du modèle sur une trentaine de groupes d’opérations.

    ÉcartéRéentraîner.

    PourquoiL’aire sous la courbe n’y serait pas fiable.

Ce qui a cassé

  1. 25 mai

    17 prix allemands signalés comme douteux : 5 réellement faux, dont 3 corrigés et 2 offres mixtes laissées vides.

  2. Collision d’identifiant de migration : la base de test n’avait pas été migrée.

  3. Premier chargement italien : arrêt après 252 lignes, fichiers protégés, et seize ans d’historique au lieu de douze mois.

  4. La source de prix gratuite n’aboutit que dans 25 % des cas réels : phase arrêtée.

Limites à ce jour

  • Aucun ordre exécuté, même en simulation.
  • Aire sous la courbe de 0,611, sous la cible de 0,65 ; le modèle distingue surtout les opérations par leur type.
  • Déploiement en attente.

Cotesmesures et dénombrements, avec leur mode de mesure

40 / 42prix allemands vérifiés sur la clause en espèces après correctiondocumenté par le projet
0,611aire sous la courbe ROC du modèle de notation, pour une cible de 0,65documenté par le projet
17migrations de schémacompté dans le dépôt
491fonctions de testcompté dans le dépôt
1 / 7décision retenue parmi les candidats de la dernière phasedocumenté par le projet

Révisions

B25 mai 2026Prix allemands corrigés
A12 mai 2026Début du projet

Nomenclaturecomposants

  1. 01Analyseursun par juridiction
  2. 02Prix offertlu sur la clause en espèces, sinon vide et signalé
  3. 03Notationmodèle entraîné sur les opérations passées
  4. 04Décisionséparée du courtier, journalisée

Notes

  1. Une offre mixte n’est jamais réduite à un seul chiffre.
  2. Une phase n’est ouverte que sur validation de la précédente.

Sources

  • 40 / 42, 17 signalésrésumé de correctif du dépôt
  • 0,611document de notation du dépôt
  • 25 %résumé de clôture de phase
  • 17 migrations, 491 testscomptage du dépôt

Ce que ça montre

Mener un système data et ML par phases, et l’arrêter sur ses propres mesures.

Planche suivante, S1Réceptionnistes vocales