D6 · Repeatability and Improvement

Ce domaine pèse 14 % de l’examen blanc — environ 7 items sur 50. C’est là où « une chose que je fais » devient « une chose que notre équipe fait » : un workflow documenté pour que quelqu’un d’autre puisse l’exécuter, versionné pour que les changements soient traçables, mesuré pour savoir s’il est bon, et amélioré sur preuves plutôt que sur le ressenti. C’est l’aboutissement de toute la piste — décomposition, contrats, choix de capacité et supervision ne composent que si le workflow est répétable et s’améliore avec le temps.

Ce qu’il faut savoir

Un workflow répétable est un workflow qu’un collègue peut exécuter de bout en bout sans vous poser de question, parce qu’il est documenté (un runbook : déclencheur, étapes, entrées, sorties, points de revue, que faire en cas d’échec). Les prompts et les configurations sont versionnés — datés, avec une note de changement — pour que vous puissiez dire ce qui a changé et revenir en arrière si un changement empire les choses. La qualité et le temps de cycle sont mesurés contre les critères d’acceptation et l’horloge, pour que l’amélioration soit jugée sur des chiffres, pas sur le ressenti. L’itération est fondée sur les preuves : changer une seule chose, mesurer, la garder seulement si la métrique s’est améliorée. Le mode de défaillance est le workflow qui ne vit que dans la tête de l’auteur, change silencieusement, et est « amélioré » par intuition sans moyen de dire s’il est réellement devenu meilleur.

Objectifs d’apprentissage

À la fin de cette page, vous devriez être capable de :

1. Documenter un workflow en un runbook qu’un collègue peut exécuter sans vous.
2. Versionner les prompts et les configurations pour que les changements soient traçables et réversibles.
3. Mesurer un workflow sur la qualité (contre les critères d’acceptation) et le temps de cycle.
4. Itérer sur des preuves : changer une variable, mesurer, garder ou revenir en arrière.
5. Reconnaître l’« amélioration » fondée sur le ressenti et le goulot d’étranglement de l’auteur unique comme des anti-schémas.

6.1 Le runbook — documenter pour la transmission

Un workflow que vous seul pouvez exécuter est un passif, pas un actif. Le test est brutal : un collègue pourrait-il l’exécuter de bout en bout sans vous poser une seule question ? Si non, il n’est pas répétable. Un runbook le rend tel.

RUNBOOK : Synthèse hebdomadaire des risques de deals
  DÉCLENCHEUR  Lundi 09:00, ou à la demande
  ENTRÉES      notes des commerciaux de la semaine ; export CRM ; (le Project détient guide de style + gabarit)
  ÉTAPES       1. Extraire les deals qui ont glissé (analyse de données sur l’export)
               2. Tirer les dernières actualités par compte du top 5 (search)
               3. Rédiger la synthèse dans le gabarit maison
               4. Point de contrôle REVUE : vérifier que les chiffres se rapprochent, ton conforme à la marque
  SORTIE       synthèse d’une page publiée sur #sales
  TERMINÉ      synthèse publiée ; aucun chiffre non rapproché
  EN CAS D’ÉCHEC  si export CRM manquant → le demander, ne pas estimer
  RESPONSABLE  Sales Ops ; secours : Ops lead

6.2 Versionner les prompts et la configuration

Les prompts et les configurations de Project/GPT dérivent à mesure que vous les retouchez. Sans versionnage, vous ne pouvez répondre à deux questions essentielles : qu’est-ce qui a changé ? et pouvons-nous revenir en arrière ?

Exemple travaillé. Un prompt de réponse de support est modifié pour « être plus concis ». Les réponses raccourcissent — et l’échantillon de satisfaction client baisse parce qu’elles omettent désormais une prochaine étape nécessaire. Parce que le changement était une unique version datée avec une note, vous revenez à la version précédente et changez ensuite uniquement la consigne de longueur tout en gardant l’instruction de prochaine étape. Sans versionnage, vous devineriez laquelle de plusieurs modifications a causé la baisse.

6.3 Mesurer la qualité

Vous ne pouvez pas améliorer ce que vous ne mesurez pas, et « ça semble mieux » n’est pas une mesure. La qualité se mesure contre les critères d’acceptation de l’étape, issus du Domaine 3.

Le point de contrôle et l’échantillonnage du Domaine 5 sont votre source de données : chaque item échantillonné est une mesure de qualité. Un workflow doté d’un régime d’échantillonnage a déjà une métrique de qualité — le taux d’erreur échantillonné — et il suffit de la suivre dans le temps.

6.4 Mesurer le temps de cycle

La qualité est la moitié du tableau ; l’autre moitié est le temps de cycle — combien de temps le workflow prend de bout en bout, et quelle part de cela est humaine vs automatisée. Le mesurer vous dit où sont réellement la valeur (et le goulot d’étranglement).

Référence manuelle :  ██████████████████████  120 min/exécution (tout humain)
Après workflow :      ████  20 min/exécution  ── dont ──
                      ██ 12 min automatisées   ██ 8 min revue humaine

Deux usages :

• Justifier le workflow. 120 → 20 minutes est le retour que vous avez passé au crible au Domaine 1.
• Trouver la prochaine amélioration. Si 8 des 20 minutes sont de la revue humaine, le plus grand levier restant est la conception de la revue (Domaine 5), pas un meilleur prompt. Mesurez avant d’optimiser, ou vous optimiserez la mauvaise étape.

6.5 Itérer sur des preuves, pas sur le ressenti

L’amélioration est une boucle : hypothèse → changer une chose → mesurer contre la métrique → garder si mieux, revenir si non. L’amélioration au « ressenti » — changer plusieurs choses parce que la sortie « semble » meilleure — ne peut vous dire ce qui a aidé, ne peut être défendue, et empire souvent silencieusement les choses.

FONDÉE SUR LES PREUVES                  FONDÉE SUR LE RESSENTI (anti-schéma)
 1 former une hypothèse                  1 retoucher plusieurs choses d’un coup
 2 changer UNE variable                  2 lire quelques sorties
 3 mesurer contre la métrique            3 « semble mieux », expédier
 4 garder ou revenir sur le chiffre      4 aucune métrique, aucune attribution, aucun retour en arrière

6.6 Boucler avec les autres domaines

La répétabilité est là où les pièces de la piste se connectent : les critères d’acceptation (D3) sont la métrique de qualité ; l’échantillonnage de revue (D5) est la source de données ; le runbook documente la décomposition (D2) et les choix de capacité (D4) ; et le retour mesuré valide l’opportunité que vous avez cadrée (D1). Un workflow documenté, versionné, mesuré et itéré est le produit fini que tout le cours Applied AI vous apprend à construire — et c’est ce qu’un collègue peut exécuter, qu’un manager peut approuver, et que vous pouvez continuer à améliorer sans deviner.

Cadre de décision

La boucle DRIVE — le cycle de maintenance d’un workflow en production.

Exécutez DRIVE chaque fois que le workflow est en production et en cours d’amélioration. La discipline est dans V et E : un changement, mesuré, gardé ou annulé sur le chiffre — jamais un paquet de retouches jugé au ressenti.

Erreurs fréquentes

Mise en situation

Situation. Sofia a construit un workflow de revue de contrats qui signale les clauses risquées et rédige une note de synthèse. Il lui fait gagner environ 90 minutes par contrat et elle en est fière. Trois choses tournent désormais mal. D’abord, elle part en congé et son secours ne peut pas l’exécuter — il existe comme un ensemble de prompts que Sofia a « en tête » et colle depuis un document de brouillon. Ensuite, le mois dernier, elle a modifié le prompt de signalement « un bon nombre de fois » pour attraper plus de types de clauses, et dernièrement il signale bien plus de faux positifs, mais elle ne peut pas dire quelle modification l’a causé. Enfin, son manager demande « est-ce réellement mieux qu’avant ? » et Sofia ne peut dire que cela « semble plus approfondi ». Elle veut continuer à régler le prompt jusqu’à ce qu’il « sonne juste ».

Trace de raisonnement expert.

1. Diagnostiquer les trois comme des défaillances de répétabilité, pas de qualité de prompt. Le secours ne peut pas l’exécuter (lacune de documentation), la régression des faux positifs est intraçable (lacune de versionnage), et « semble plus approfondi » (lacune de mesure). Aucune n’est corrigée par plus de réglage de prompt ; le réglage au ressenti est précisément ce qui a créé la régression.
2. Corriger la transmission avec un runbook. Écrire le déclencheur, les entrées, les étapes ordonnées avec leurs capacités, le point de contrôle, la définition de « terminé », et que faire quand un contrat manque une section — pour que le secours l’exécute sans aide. « Enregistrer une vidéo » ou « ils se débrouilleront » échoue au test sans-question.
3. Introduire le versionnage pour isoler la régression. Les faux positifs sont apparus après « un bon nombre de » modifications non datées, donc il n’y a aucun moyen d’attribuer ou de revenir en arrière. Adopter des versions datées avec des notes de changement d’une ligne, restaurer la dernière version connue pour avoir un faible taux de faux positifs, puis réappliquer les ajouts individuels de types de clauses un à la fois, en mesurant après chacun, pour trouver la modification qui a introduit le bruit.
4. Instrumenter la qualité et le temps de cycle. Définir les critères d’acceptation (quels types de clauses doivent être signalés ; taux de faux positifs acceptable) et mesurer le taux d’erreur/faux positifs échantillonné et le temps de bout en bout. Désormais « est-ce mieux ? » a une réponse : un chiffre, avant et après, contre une référence.
5. Passer à l’itération fondée sur les preuves. Remplacer « régler jusqu’à ce que ça sonne juste » par la boucle DRIVE : émettre une hypothèse, changer une règle de type de clause, mesurer le taux de faux positifs sur un échantillon fixe, garder ou revenir. Cela corrige à la fois la régression actuelle et prévient la suivante.
6. Répondre correctement au manager. Non pas « ça semble plus approfondi » mais « sur un échantillon de 40 contrats, il signale 96 % des types de clauses cibles (la référence était manuelle) à un taux de faux positifs de 8 %, en baisse depuis 19 % la semaine dernière après annulation de la mauvaise modification, et réduit le temps de revue de ~110 à ~20 minutes ».

La décision : traiter les problèmes comme des lacunes de documentation, de versionnage et de mesure — écrire le runbook, adopter un versionnage daté un-changement-à-la-fois pour isoler et annuler la régression, et instrumenter la qualité et le temps de cycle pour que l’itération soit fondée sur les preuves — pas « continuer à régler jusqu’à ce que ça sonne juste », qui est l’anti-schéma du ressenti ayant causé la régression au départ.

Pièges de l’évaluation

Questions d’entraînement

Chaque item indique combien de réponses sélectionner. Décidez avant de dévoiler.

À retenir

• Un workflow répétable est documenté en un runbook — déclencheur, étapes avec capacités, points de revue, définition de « terminé », gestion des échecs, responsable — pour qu’un collègue l’exécute sans vous poser de question.
• Versionner les prompts et les configurations : les dater, noter le changement, garder la version précédente, changer une chose à la fois — pour que les effets soient attribuables et les régressions réversibles.
• Mesurer la qualité contre les critères d’acceptation (en utilisant le régime d’échantillonnage comme source de données) et mesurer le temps de cycle pour trouver le vrai goulot d’étranglement.
• Itérer sur des preuves, pas sur le ressenti : hypothèse → un changement → mesurer → garder ou revenir. « Ça semble mieux » n’est pas une mesure.
• Mesurer avant d’optimiser, ou vous réglerez le prompt alors que l’étape de revue était le goulot d’étranglement.
• La répétabilité boucle la piste : les critères D3 sont la métrique, l’échantillonnage D5 est la donnée, le runbook enregistre D2 et D4, et le retour en temps de cycle valide l’opportunité D1.
• La boucle DRIVE — Document, Record versions, Instrument, Vary one thing, Evaluate — est le cycle de maintenance d’un workflow en production.