Ce qu’il faut écrire avant d’automatiser quoi que ce soit

Le périmètre, en une page

La plupart des projets d’automatisation qui dérapent n’ont jamais eu de périmètre écrit. Le prestataire propose, le client acquiesce, et six semaines plus tard chacun découvre qu’il parlait d’autre chose.

Le périmètre tient en une page et répond à quatre questions. Quel processus exactement, depuis quel déclencheur jusqu’à quelle sortie. Quels cas sont couverts et lesquels ne le sont pas. Quels outils sont concernés. Et ce qui reste manuel après la mise en service.

Le quatrième point est celui qu’on oublie. Une automatisation ne supprime jamais cent pour cent du travail, et le dire à l’avance évite la déception qui tue les projets suivants.

Le point de validation, décidé avant de construire

Chaque processus contient un moment où quelque chose engage l’entreprise. Un prix qui part, une signature, une réponse à une réclamation, un envoi à un client mécontent.

Ce moment est le point de validation. Il se décide avec le dirigeant, avant que la première ligne de configuration ne soit écrite, parce que sa position change toute l’architecture.

Placer la validation trop tôt annule le gain de temps. La placer trop tard fait sortir des choses que personne n’a vues.

La règle que nous appliquons est simple. Tout ce qui prépare peut être automatique. Tout ce qui engage passe par un humain.

La procédure d’erreur, avant la mise en service

Un système qui tourne rencontrera un cas qu’il ne sait pas traiter. Un champ vide, une donnée contradictoire, un client qui n’existe pas dans le fichier, un fournisseur qui change son format.

Ce qui compte n’est pas de promettre que ça n’arrivera jamais. C’est d’écrire, avant la mise en service, ce qui se passe à ce moment-là.

Trois lignes suffisent. Le système s’arrête sur le cas plutôt que de deviner. Quelqu’un reçoit une alerte avec le dossier concerné et ce qui manque. La reprise se fait à la main sur ce dossier, sans arrêter le reste.

Sans cette procédure, une erreur se découvre trois semaines plus tard, quand un client rappelle, et le coût de la découverte tardive dépasse largement celui de l’erreur elle-même.

Pourquoi trois documents et pas un cahier des charges

Un cahier des charges de quarante pages ne se lit pas, ne se met pas à jour, et donne l’illusion que tout a été prévu. Trois documents courts se relisent en dix minutes avant chaque décision.

Ils servent aussi de preuve. Quand le système fait quelque chose d’inattendu, la question devient factuelle : est-ce dans le périmètre, la validation était-elle au bon endroit, la procédure d’erreur a-t-elle joué. Personne ne discute d’impressions.