Quand ça doit mourir

Fiche courte, et personne ne la fait. Un parc d’automatisations s’entretient aussi en supprimant.

Une automatisation qui n’a plus de raison d’être ne coûte pas seulement des exécutions. Elle consomme de l’attention à chaque revue, elle brouille les alertes, et elle fait circuler des données pour rien.

Les cinq signes

Personne ne lit plus le résultat. Le destinataire est parti, le tableau n’est plus ouvert, le rapport arrive dans une boîte inactive. Vérifiable en une question.

Le logiciel qu’elle alimente est remplacé. Elle continue d’écrire dans un système que plus personne n’utilise.

Le processus a changé. Elle applique une règle qui n’est plus la bonne, et le service a repris la tâche à la main sans le dire.

Elle est en panne depuis longtemps et personne ne s’en est plaint. Le signe le plus clair de tous. Si trois semaines d’arrêt n’ont produit aucune réclamation, la question se pose sérieusement.

Le service branché propose désormais la fonction nativement. Ça arrive régulièrement, et l’enchaînement fait doublon avec une fonction incluse dans un logiciel déjà payé.

Le test de l’arrêt

Quand tu hésites, ne débats pas : mesure.

Désactive l’enchaînement, note la date, et attends. Deux à quatre semaines selon sa fréquence.

Si personne ne dit rien, supprime.

Si quelqu’un se manifeste, tu viens d’apprendre deux choses : à quoi il servait vraiment, et qui en dépend. Réactive, et note ces deux informations dans son dossier.

C’est brutal, c’est gratuit, et c’est plus fiable que toutes les discussions sur l’utilité supposée. Réserve-le évidemment aux enchaînements classés « confort ».

Arrêter proprement

Supprimer un enchaînement demande cinq minutes de plus que le désactiver, et ces cinq minutes évitent les ennuis.

Fait ?	L’étape
☐	Prévenir les personnes qui recevaient quelque chose
☐	Vérifier qu’aucun autre enchaînement ne dépend de ce qu’il produisait
☐	Révoquer les accès et les connexions qui ne servent plus qu’à lui
☐	Vérifier ce qui reste dans la branche « à vérifier », et le traiter
☐	Noter la suppression au registre, avec la date et la raison
☐	Exporter ou noter la logique, si elle pourrait resservir
☐	Vérifier si un traitement doit être retiré du registre des traitements

La deuxième ligne est celle qui produit des surprises : les enchaînements se branchent souvent les uns sur les autres, et supprimer une source casse un consommateur silencieusement.

La dernière ligne compte si des données personnelles circulaient : l’arrêt d’un traitement se répercute au registre, et les données conservées doivent être traitées.

Le nettoyage annuel

Une heure par an, et il vaut mieux qu’une politique.

Ouvre le registre. Pour chaque ligne, trois questions.

Est-ce que ça tourne encore ? Regarde la date de dernière exécution réussie.

Est-ce que quelqu’un en dépend ? Le propriétaire répond.

Est-ce que ça sert encore à quelque chose ? La question la plus difficile, et celle qui supprime le plus.

Sur un parc de trente automatisations construites en deux ans, ce nettoyage en supprime généralement plusieurs. C’est un bon résultat, pas un aveu d’échec : construire des choses qui deviennent inutiles est normal, les laisser tourner ne l’est pas.

Le cas de l’automatisation qui masque un problème

Situation à repérer, parce qu’elle demande autre chose qu’une suppression.

Une automatisation existe parfois pour compenser un défaut ailleurs : une double saisie entre deux logiciels qui ne communiquent pas, un recopiage manuel dû à un mauvais paramétrage, un contournement d’une limitation qu’on pourrait lever.

Elle rend service, et elle rend le problème invisible. Personne ne demande plus la correction, puisque la douleur a disparu.

Quand tu repères ce cas, écris-le dans le dossier : « cet enchaînement compense telle limitation ; si elle est levée, il devient inutile. »

C’est ce qui permettra, un jour, de régler le problème plutôt que de l’entretenir.

Ce qui reste après

Un dernier point, souvent oublié.

Quand une automatisation disparaît, la tâche revient à quelqu’un, ou elle disparaît aussi. Dis laquelle.

Si la tâche revient, la procédure de reprise manuelle du dossier devient la procédure tout court. C’est le moment où elle sert, et c’est pour ça qu’elle a été écrite.

Vérifie ta compréhension

Question : tu découvres qu’un enchaînement est en panne depuis sept semaines et que personne ne s’en est plaint. Tu le répares ?

Réponse : pas tout de suite. Sept semaines sans réclamation est le signe le plus clair qu’il ne servait plus, ou que quelqu’un a repris la tâche à la main sans le dire. Va poser la question au service concerné avant de réparer : soit tu supprimes proprement, avec la liste de contrôle, soit tu apprends que la tâche est refaite manuellement depuis deux mois, ce qui est une information utile. Réparer sans demander revient à remettre en route quelque chose dont personne n’a besoin, et à recommencer dans six mois.

L’atelier 2 produit le dossier et le registre, pour que tout ça survive.