Le plus simple pour savoir qu'un système a cassé, c'est qu'il lève une erreur. Le cas difficile est celui qui fonctionne mal sans en lever : tout paraît correct à l'écran alors que la sortie est silencieusement fausse. Cette leçon indique où regarder, et dans quel ordre, quand cela arrive.
Cette leçon prend le moment où une automatisation déjà construite cesse de se comporter comme prévu. Le but est que vous trouviez le problème en le resserrant dans l'ordre plutôt qu'en devinant, et que la correction trouvée tienne dans la durée. Une automatisation reste debout dès lors que le diagnostic cesse de dépendre de la personne qui a construit le système et devient un savoir faire de l'entreprise.
À la fin, vous tenez un ordre de diagnostic, une fiche de panne remplie et une étape de vérification qui montre que la correction a servi. Les interventions faites sans ces trois éléments produisent souvent une deuxième panne.
Prérequis : la carte de processus de la première leçon. C'est l'attente écrite à laquelle vous comparez pendant la recherche.
La phrase ça ne marche pas recouvre trois situations à la fois, et chacune se diagnostique depuis un point de départ différent. Séparer dès le début de la conversation le type auquel vous avez affaire resserre tout de suite la zone de recherche.
L'automatisation ne tourne pas du tout. Le déclencheur n'arrive pas ou elle tombe à la première étape. C'est le type le plus facile, parce que le symptôme se voit et laisse en général une trace dans le journal.
Le flux tourne, produit des fiches, ne lève aucune alerte ; et pourtant le résultat est faux. C'est le type le plus coûteux, parce que l'erreur s'accumule des semaines durant et que le nettoyage remonte en arrière une fois la chose remarquée.
Le résultat est juste mais n'arrive pas à temps. Il s'agit rarement d'une panne unique, plutôt d'une charge accumulée ou d'une étape récemment ajoutée. Sans mesure, ce type reste discutable.
Ce que les trois partagent : tant que l'attente reste non écrite, la panne ne peut pas être définie. La phrase ça n'aurait pas dû être comme ça ne devient pas un diagnostic sans un ça aurait dû être comme ça mis par écrit.
Une automatisation casse rarement dans le bruit. Aucun message d'erreur, rien ne passe au rouge, le flux paraît vert. La sortie est fausse tout de même : le message part à la mauvaise personne, un champ reste vide, une fiche s'ouvre deux fois, la date s'écrit dans un autre format.
La source d'une panne silencieuse est le plus souvent l'entrée qui change de forme. Un nouveau champ s'ouvre dans le formulaire, le portail se met à envoyer le numéro autrement, un salarié remplit le champ différemment. La règle reste la même, l'entrée change, et le résultat glisse en silence.
Le dernier point pèse le plus. Dès que l'équipe corrige une sortie à la main, le système est déjà cassé ; comme personne ne l'a signalé, la panne n'est entrée dans aucun journal.
Si une chose qui marchait hier ne marche plus aujourd'hui, quelque chose a changé entretemps. C'est la première question du diagnostic, et la plupart des pannes se referment dessus. Dans les systèmes sans liste de changements, la même question prend des heures.
Le changement n'a pas lieu que dans le système. Il a lieu aussi dans le processus, chez les personnes et dans l'entrée. Un salarié est peut être parti, un portail a renommé un champ, un fournisseur a renouvelé un format de fichier. Commencez la recherche par cette liste, pas par l'intérieur du code.
Le diagnostic commence quand le symptôme est écrit. Ça ne marche pas n'est pas un symptôme, c'est une impression. Le symptôme, c'est ceci : sur quelle fiche, quand, ce qui était attendu, ce qui est arrivé à la place. La zone de recherche ne se resserre pas tant que ces quatre champs ne sont pas remplis.
En écrivant le symptôme, prenez le résultat attendu dans la carte de processus de la première leçon. S'il n'y a pas de carte, elle s'écrit d'abord ; un diagnostic mené sans attente écrite revient à comparer la mémoire d'une personne au comportement du système.
Les deux dernières questions donnent la direction du diagnostic. Si la panne est sur une seule fiche, le problème se situe plutôt dans l'entrée ; sur toutes, dans la règle ; sur une partie, dans la condition.
Ne réparez pas ce que vous ne pouvez pas reproduire. Sans un exemple qui répète la panne quand vous le voulez, vous ne pouvez pas non plus montrer que votre changement a servi. Beaucoup de pannes réputées réglées sont des pannes qui ne se sont pas répétées ce jour là.
Reproduire veut dire faire passer la même fiche dans un environnement d'essai ou avec un exemple inoffensif. Si vous devez essayer sur le système vivant, choisissez une étape réversible et prévenez l'équipe à l'avance.
Le moyen le plus rapide de resserrer la zone de recherche est de couper le flux en son milieu. En un point du milieu, la donnée est elle juste ou fausse ? Si elle est juste, la panne est dans la seconde moitié ; si elle est fausse, dans la première. Chaque coupe laisse la moitié du terrain à examiner.
Cette méthode fonctionne indépendamment de l'outil. La même question se pose en regardant l'écran de la fiche, la table intermédiaire, le message envoyé ou le journal tenu par le système : la donnée est elle arrivée juste jusqu'ici ?
Écrivez le résultat après chaque coupe. Les coupes non écrites se répètent, et le diagnostic s'allonge parce qu'on regarde les mêmes endroits une deuxième fois.
Une fois la zone resserrée, sondez dans l'ordre les cinq parties de la première leçon. Les six sources ci dessous sont celles que l'on rencontre le plus sur le terrain, et la plupart des diagnostics se referment à l'intérieur.
L'événement n'est peut être pas arrivé du tout. La liaison a pu tomber, une autorisation a pu expirer, une adresse a pu changer. Si aucune fiche n'a été créée, la panne est à la porte du flux, pas dedans.
C'est la source la plus fréquente. Un champ a pu être renommé, une date peut arriver dans un autre format, un zéro initial a pu tomber, une espace ou une majuscule peut différer.
Une situation nouvelle a pu apparaître et tomber hors des chemins écrits. Les fiches en dehors des conditions tombent en général en silence, parce qu'aucun chemin n'a été écrit pour elles.
Un mot de passe a pu changer, une clé a pu expirer, un accès a pu être supprimé. Ces pannes commencent brutalement un jour et ne préviennent pas avant.
Deux étapes ont pu tourner dans le mauvais ordre, ou l'une a démarré sans attendre la donnée de l'autre. Les pannes qui sortent aux heures chargées et pas aux heures calmes sont en général ici.
L'autre bout a pu refuser : un champ est devenu obligatoire, une limite s'est remplie, un format a été rejeté. Quand la réponse qui revient n'est pas lue, cette panne reste muette.
Ne changez pas plusieurs choses en même temps. Si vous faites deux changements et que le résultat s'améliore, lequel a aidé reste inconnu ; s'il se dégrade, lequel a cassé reste inconnu. À ce point, le diagnostic redevient une devinette.
Après chaque changement, refaites passer l'exemple de l'étape deux. La vérification couvre autant le départ de la panne que l'absence de casse ailleurs. Pour cela, notez d'avance quelles fiches tournaient correctement.
Faire partir la panne, c'est la moitié du travail. L'autre moitié consiste à poser les repères qui empêchent la même panne de se reformer en silence. Sans cela, le même diagnostic se refait de zéro quelques mois plus tard.
La durée vient de trois choses : une alerte là où la panne se montrerait, un contrôle qui sonde les limites de l'entrée, et une voie d'exception définie. Les trois tiennent dans l'automatisation elle même et ne demandent pas de système à part.
Déroulons la méthode sur une seule panne, d'un bout à l'autre. L'exemple passe par un flux commercial, mais l'ordre est le même dans tous les flux.
Symptôme : les clients ayant fait une nouvelle demande ne reçoivent pas le courriel d'offre. L'équipe commerciale l'a remarqué la première et dit que plusieurs clients attendaient une réponse la semaine passée. Les fiches semblent avoir été créées.
Ce qui a changé : un nouveau champ a été ajouté au formulaire ces deux dernières semaines et une mise à jour a eu lieu côté portail. Deux candidats.
Reproduction : l'une des fiches touchées repasse avec la même entrée. La panne se répète, un exemple mesurable est donc en main.
Coupe en deux : on regarde la table du milieu du flux. La fiche y est, mais le champ de l'adresse courriel est vide. La panne est donc dans la première moitié, côté entrée.
Cinq parties : on regarde le format d'entrée. Le nouveau champ du formulaire a renommé le champ courriel. Le flux cherche l'ancien nom, ne le trouve pas, passe une valeur vide, et l'étape du courriel tombe en silence.
Un changement et vérification : le flux est corrigé pour lire le nouveau nom de champ. L'exemple de la panne repasse et le courriel part. Deux fiches qui tournaient bien avant repassent aussi, et elles vont toujours bien.
Durée : si le champ courriel est vide, le flux s'arrête, la fiche passe en attente et la direction est prévenue. Le nom du champ est mis à jour sur la carte de processus. L'autre flux utilisant ce champ est sondé et corrigé lui aussi.
Le diagnostic n'est pas un savoir faire à apprendre le jour où la panne sort. Répété un jour calme, il est prêt le jour où il faut. C'est à cela que sert l'exercice ci dessous.
Tout flux qui passe en silence est un flux qui produira plus tard une panne silencieuse. Cet exercice en fait remonter au moins un dans la plupart des entreprises.
Télécharger la liste de diagnostic (xlsx) · la fiche de panne, ce qui a changé, la coupe du flux en deux, le contrôle des cinq parties et les étapes de la correction durable.
Le premier endroit examiné est en général la règle, alors que la source la plus fréquente est l'entrée. Si la règle n'a pas bougé depuis hier, ce qui a changé, c'est plutôt la donnée qui lui parvient.
Faire deux changements et regarder le résultat ne termine pas le diagnostic, cela le brouille. Quel changement a fait quoi reste inconnu, et la correction devient impossible à répéter.
Une correction faite sur une panne non reproductible ne peut pas être vérifiée. La panne reste invisible un temps, puis revient au même endroit.
La plupart des flux notent quelque part ce qu'ils ont fait. Un diagnostic sans lire le journal, c'est deviner sans écouter ce que dit le système.
Un symptôme transmis de bouche à oreille change à chaque passage. Un symptôme non écrit devient un diagnostic où deux personnes cherchent deux pannes différentes.
Une panne refermée sans alerte ni contrôle revient sous la même forme. À sa deuxième venue, le diagnostic recommence et la confiance s'use encore.
Avant de refermer une panne, il vaut mieux pouvoir dire oui à chacun des points ci dessous. S'il en manque un, la panne n'est pas refermée, elle est reportée.
Les termes qui reviennent dans les discussions de diagnostic. Dès que l'équipe partage un vocabulaire, la transmission d'une panne va plus vite.
Dans cette leçon nous avons vu comment resserrer une panne dans l'ordre et rendre la correction durable ; vous avez vu qu'une grande part des pannes sort du côté de l'entrée.
Les modules restants du programme sont en préparation. À mesure de leur parution, ils prennent leur place dans le programme et apparaissent sur la page formation.
Le registre des exceptions, la voie d'alerte et la mesure qui rend visible la panne silencieuse.
Le dictionnaire de champs et les règles de forme. La plupart des pannes commencent de ce côté.
La section formation dans son ensemble et les modules ajoutés depuis.
Si vous soupçonnez qu'un système se trompe en silence, écrivez-nous et nous regarderons ensemble.
Demander un Devis sur WhatsApp