Tester avant de brancher
Une automatisation testée sur un cas normal marchera sur les cas normaux. Ce sont les autres qui posent problème, et ils arrivent la deuxième semaine.
Le jeu de cas
Section intitulée « Le jeu de cas »Il existe déjà : c’est la liste des cas particuliers sortie à la cartographie, quand tu as demandé « qu’est-ce qui arrive une fois sur dix ».
Reprends-la et ajoute quatre cas tordus, qu’on essaie toujours, quel que soit le processus.
Le cas vide. Aucun élément à traiter, champ non rempli, pièce jointe absente. L’enchaînement doit se terminer proprement, sans envoyer un message vide à quelqu’un.
Le cas énorme. Deux cents lignes d’un coup, un fichier de trente mégaoctets, un texte très long. Il révèle les limites de durée et de quota.
Le cas mal formé. Une date au mauvais format, un montant avec une virgule, un accent, une apostrophe, un nom en majuscules. C’est ici que se cachent la plupart des pannes silencieuses.
Le doublon. Le même élément arrive deux fois. Ta protection de la fiche précédente fonctionne-t-elle vraiment ?
Cinq à dix cas au total. Écris-les avant de construire, pas après : écrits après, ils décrivent ce que l’enchaînement sait déjà faire.
Tester sans conséquence
Section intitulée « Tester sans conséquence »Règle absolue de cette fiche.
On ne teste jamais sur les vrais destinataires.
Trois façons de s’en assurer, et la première suffit souvent.
Remplace les destinataires par ta propre adresse pendant tout le développement.
Utilise un environnement de test quand le service en propose : un tableau de test, une boîte dédiée, un compte bac à sable.
Et sur les actions à effet réel, mets un filtre temporaire qui les bloque : « continuer seulement si le champ test vaut oui ».
Le nombre de personnes qui ont envoyé un mail de test à une liste de clients réels est plus élevé qu’on ne l’imagine.
La mise en service progressive
Section intitulée « La mise en service progressive »Ne branche pas tout d’un coup. Quatre étapes, sur deux semaines, et chacune a un critère de passage.
Étape 1, à blanc. L’enchaînement tourne sur des données réelles, mais toutes les actions à effet externe sont désactivées. Il écrit seulement dans un tableau ce qu’il aurait fait.
Laisse tourner deux ou trois jours et lis ce tableau. C’est l’étape la plus instructive, et c’est celle qu’on saute.
Étape 2, en parallèle. L’enchaînement agit, et la personne continue à faire la tâche à la main. On compare. Coûteux quelques jours, et ça rassure tout le monde.
Étape 3, sous surveillance. L’enchaînement fait le travail, quelqu’un vérifie chaque jour pendant une semaine.
Étape 4, en régime. La surveillance devient automatique, et c’est l’objet du module suivant.
Pour un enchaînement à faible conséquence, on peut sauter l’étape 2. Pour un enchaînement qui touche des clients ou de l’argent, on ne saute rien.
Ce qu’on vérifie à chaque test
Section intitulée « Ce qu’on vérifie à chaque test »Une petite liste, à passer sur chaque cas du jeu.
| Vérifié ? | Le point |
|---|---|
| ☐ | Le résultat est celui attendu, valeur par valeur |
| ☐ | Aucun doublon n’a été créé |
| ☐ | Le cas non traité est parti dans la branche « à vérifier » |
| ☐ | Les valeurs aberrantes déclenchent le contrôle de vraisemblance |
| ☐ | La durée d’exécution reste loin de la limite |
| ☐ | Rien n’est parti vers un vrai destinataire |
La dernière ligne se vérifie avant de lancer, pas après.
Documenter au fur et à mesure
Section intitulée « Documenter au fur et à mesure »Trois lignes à écrire pendant que tu construis, pendant que tu sais encore pourquoi.
Ce que fait l’enchaînement, en une phrase, et pour qui.
Les décisions non évidentes : pourquoi ce filtre, pourquoi cet ordre d’étapes, pourquoi cette valeur par défaut.
Les cas connus qu’il ne traite pas.
Écrites après coup, ces trois lignes sont fausses ou absentes. C’est le début du dossier de l’atelier 2.
Le test de reprise
Section intitulée « Le test de reprise »Un dernier essai, que presque personne ne fait, et qui vaut la peine.
Casse volontairement l’enchaînement : déconnecte un service, mets un mauvais identifiant, envoie une donnée absurde.
Regarde ce qui se passe. Est-ce que tu es prévenu ? Est-ce que la donnée est perdue ? Est-ce que l’enchaînement redémarre tout seul quand tu répares, ou faut-il rejouer les cas manqués à la main ?
Les réponses à ces trois questions sont le vrai niveau de maturité de ton automatisation, et c’est le sujet du module 3.
Vérifie ta compréhension
Question : ton enchaînement fonctionne parfaitement sur les douze cas que tu as essayés. Tu le branches lundi ?
Réponse : pas directement en production. Passe d’abord trois jours à blanc, avec les actions externes remplacées par une écriture dans un tableau « ce que j’aurais fait ». Douze cas choisis par toi couvrent ce à quoi tu as pensé ; trois jours de données réelles couvrent ce à quoi tu n’as pas pensé, et c’est précisément là que se trouvent les problèmes. Vérifie aussi que tu as essayé les quatre cas tordus, dont le doublon, qui est celui qui coûte le plus cher en production.
L’atelier 1 construit votre première automatisation, du déclencheur au fonctionnement à blanc.
Une formationBaxIA