Étude de cas · Routine
Diagnostiquer et réparer un système qui ne se parle plus
Des briques qui marchaient chacune de leur côté, mais dont les liaisons s'étaient rompues sans bruit. Quatre relevés, une carte, un passage sur toutes les flèches, des corrections relues depuis leur source, puis une surveillance qui constate sans réparer.
Idée
Quel problème, en une phrase ?
Constater que les briques ne se parlent plus
Chaque brique marchait seule : le tri des mails, le tableau de bord, les tâches planifiées, la sentinelle. Mais les flèches entre elles s'étaient rompues sans bruit. Le symptôme n'était pas une panne visible, c'était un silence : rien ne signalait que rien ne circulait.
DifficultéUne décision attendue depuis des jours, que personne ne présentait : elle dormait dans un rapport que rien ne relisait.
SolutionToute question en attente va dans une file de décisions unique, lue par le tableau de bord.
DifficultéDes passages de routine notés « réussis » qui n'avaient rien produit.
SolutionUn passage n'est réussi que s'il laisse une trace datée du jour : journal, fichier ou ligne de tableau.
DifficultéDes tâches planifiées qui ne voyaient pas les plugins installés dans la session interactive.
SolutionChaque tâche déclare ce dont elle a besoin et vérifie au démarrage que c'est disponible ; sinon elle s'arrête en le disant.
DifficultéUne sentinelle qui ne voyait pas les pannes, parce qu'elle lisait les mêmes journaux que les briques qu'elle surveillait.
SolutionLa sentinelle vérifie les produits (fichiers, pages, lignes), pas les déclarations.
!Un système silencieux n'est pas forcément un système en bonne santé : l'absence d'alerte doit elle-même être vérifiée.
Concept
Que sera l'outil, et que fera-t-il ?
Faire quatre relevés
Avant de réparer, relever l'existant en quatre volets : les conversations (ce qui a été demandé et fait), les skills et les connecteurs (ce qui est installé, où, et pour quel usage), les tâches planifiées et le tableau de bord (ce qui tourne et ce qui s'affiche), le site public (ce qui est publié). Chaque relevé est daté et dit ce qu'il n'a pas pu lire.
À dire à Claude« Fais quatre relevés de mon système sans rien modifier : conversations des deux derniers mois, skills et connecteurs installés, tâches planifiées et tableau de bord, site public. Pour chaque élément : où il vit, ce qu'il lit, ce qu'il écrit et sa dernière trace datée. Termine par ce que tu n'as pas pu consulter. »
DifficultéLes mêmes skills installés à deux endroits, dans deux versions différentes.
SolutionLe relevé note la version et l'emplacement de chaque copie ; une seule source fait foi, les autres en dérivent.
Dessiner la carte et passer sur toutes les flèches
Une carte du système : chaque brique est une boîte, chaque échange une flèche (qui écrit quoi, qui le lit, à quel moment). Puis un passage sur toutes les flèches, une par une : la source écrit-elle bien ? La cible lit-elle au même endroit ? Une flèche sans lecteur, ou un lecteur sans source, est une panne en attente.
DifficultéDes chemins de fichiers écrits pour un ancien ordinateur, encore utilisés par certaines tâches.
SolutionLes chemins sont regroupés dans un seul fichier de configuration, que chaque brique relit.
!Plusieurs dizaines de flèches : ne pas les vérifier de mémoire, mais une par une, avec une preuve.
Réalisation
Que demander à Claude, dans quel ordre ?
Tester à blanc et lister problème → solution
Chaque élément est lancé à blanc, sans rien écrire, pour voir ce qu'il lirait et ce qu'il produirait. Chaque écart devient une ligne problème → solution sur une page où un bouton copie le prompt de correction, prêt à coller dans une nouvelle conversation.
DifficultéUn test à blanc qui écrivait quand même dans le journal réel.
SolutionUn mode d'essai explicite, qui écrit dans un dossier de test et l'annonce en tête de sa sortie.
Restituer en quatre blocs
La restitution tient en quatre blocs : ce que Claude corrige sans accord (une coquille dans un fichier de règles), ce qui demande l'accord (modifier une tâche, toucher une page publiée), les chemins à harmoniser, et ce qui ne relève que de la personne : reconnecter un compte, installer un plugin sur un poste, choisir entre deux options. Ce dernier bloc s'intitule « il ne reste que vous ».
À dire à Claude« Voici la liste problème → solution. Range chaque ligne dans l'un des quatre blocs : sans accord, avec accord, chemins, il ne reste que vous. Pour chaque ligne du bloc « avec accord », écris la question à me poser et l'option que tu recommandes. »
DifficultéUne liste de plusieurs dizaines de corrections, illisible d'un seul tenant.
SolutionLe bloc « il ne reste que vous » est court et placé en tête : c'est la seule partie qui attend une action humaine.
Épreuve
Comment prouver que ça marche ?
Exécuter les accords, puis relire chaque écriture depuis sa source
Une fois les accords donnés, Claude exécute, puis vérifie chaque écriture par un aller-retour : il relit le fichier, la page ou la ligne depuis l'endroit où la brique destinataire la lira, et non d'après ce qu'il croit avoir écrit.
DifficultéUne correction annoncée comme faite, mais écrite dans une copie que personne ne lisait.
SolutionAucune correction n'est déclarée faite sans relecture depuis la source réelle, preuve à l'appui (date, extrait).
!Une correction non relue est une hypothèse, pas un fait.
Ajouter deux contrôles nés du diagnostic
Deux contrôles nouveaux entrent dans la surveillance : « tâche réussie mais sans journal du jour », qui débusque les passages vides, et « le chemin utilisateur correspond au poste courant », qui débusque les chemins hérités d'un ancien ordinateur.
Mise en service
Comment le livrer, le publier, le faire durer ?
Un moniteur à voyants
Un moniteur regroupe les voyants par groupe (mail, agenda, tableau de bord, tâches, site, connecteurs). Il teste les connecteurs en direct, affiche des alarmes acquittables avec leur historique, et une carte du système où la flèche en panne clignote.
DifficultéDes alarmes restées rouges après correction, qui finissaient ignorées.
SolutionChaque alarme s'acquitte à la main, avec la date et le motif ; une alarme acquittée qui revient remonte en tête.
Un audit dominical, un juge séparé, une page d'arbitrages
Chaque dimanche, un audit relit le système avec l'âge de chaque alerte et la dormance des projets. Le juge est séparé de ce qu'il juge : la sentinelle constate, elle ne répare jamais. Les questions qu'elle soulève vont sur une page d'arbitrages système, une fiche par question avec une option recommandée, et rien ne change avant la réponse.
DifficultéUne sentinelle qui corrigeait elle-même ce qu'elle trouvait, et masquait ainsi les pannes récurrentes.
SolutionConstater et réparer sont deux rôles distincts ; la réparation passe par l'arbitrage, puis par une relecture.
!Le détail de l'audit hebdomadaire et de la page d'arbitrages figure dans la fiche sur l'inventaire croisé.