Quand ne pas automatiser : la règle de décision que j'applique avant de construire quoi que ce soit

J’ai supprimé plus d’automatisations que je n’en fais tourner aujourd’hui. Pas parce qu’elles étaient en panne, mais parce qu’elles fonctionnaient parfaitement et aggravaient les choses.

Cette phrase mérite qu’on s’y arrête, car c’est exactement ce que la communauté du « tout automatiser » n’aborde jamais. Une automatisation qui tourne de façon fiable et dégrade la qualité de votre travail n’est pas un gain de productivité. C’est un passif déguisé en atout. Le seul signal qui le révèle, c’est de remarquer, plusieurs semaines après coup, que les résultats que vous produisez se sont discrètement dégradés, et que l’automatisation masquait ce déclin.

Voici la règle de décision que j’applique désormais avant de construire quoi que ce soit. C’est une seule question avec trois sous-vérifications, et elle m’a fait gagner plus de temps que la plupart des automatisations que j’aurais construites sans elle.

Les cas qui m’ont appris la règle

J’ai construit quatre automatisations que j’ai supprimées par la suite. Toutes les quatre fonctionnaient. Voici ce qu’elles faisaient et pourquoi elles sont parties.

Résumés automatiques de réunions. Un modèle tournant sur chaque transcription de réunion : des résumés instantanés envoyés trente minutes après chaque appel. Le problème : les résumés étaient précis et inutiles. Les notes de réunion ont besoin d’un travail de curation, pas de compression. L’automatisation faisait apparaître ce qui avait été dit proportionnellement à la quantité de mots. Ce qui comptait réellement dans la plupart des réunions, c’était une phrase prononcée une seule fois, avec hésitation, que j’aurais annotée et sur laquelle j’aurais construit le brief. Cette phrase ne ressortait pas dans un résumé. Elle se confondait avec les quarante-neuf autres phrases. L’automatisation produisait une documentation propre et bien formatée des parties les moins importantes de chaque réunion.

Remplacé par : le système d’annotation à trois étiquettes. Manuel. Non automatisable.

Brouillons automatiques de relance client. Un modèle rédigeant des e-mails de relance à partir du résumé de réunion. Le problème : il appliquait un registre professionnel uniforme à des relations qui exigeaient un traitement différencié. Un client voulait de la brièveté et de la franchise. Un autre avait besoin de chaleur et de contexte. Un autre se trouvait dans une position politiquement sensible qui exigeait un cadrage soigné. Le modèle produisait des relances correctes, fluides, professionnelles. Elles étaient inadaptées à la relation, de la même façon qu’une carte de condoléances préécrite est inadaptée : grammaticalement irréprochable, situationnellement décalée. Trois clients ont répondu sur un ton qui m’a fait comprendre qu’ils avaient perçu l’absence d’une vraie personne en face. L’automatisation était techniquement correcte ; les résultats étaient professionnellement faux.

Remplacé par : rien. Certaines relances doivent être écrites à la main.

Digests de briefing. Un digest quotidien de tout ce qui était marqué important dans mes notes de la semaine passée. Le problème : l’habitude des digests quotidiens m’a rendu moins sélectif sur ce que je marquais comme important. Quand un système agrège tout, on perd la discipline qui consiste à décider ce qui compte avant même de le capturer. Le digest s’accumulait. L’exhaustivité a remplacé la sélectivité, alors que la sélectivité était tout l’enjeu.

Remplacé par : une revue manuelle hebdomadaire de quinze minutes sur les notes brutes de la semaine. Je choisis les trois choses qui ont réellement fait bouger quelque chose. Cette contrainte est structurante.

Scores de confiance. J’ai demandé au modèle de noter ses propres résultats de recherche sur une échelle de confiance de 1 à 10. Le problème : les chiffres étaient inventés. Le modèle faisait du pattern-matching sur ce à quoi ressemble un score de confiance et produisait des chiffres plausibles. Je m’y fiais. J’avais automatisé l’imitation du jugement et je l’avais confondue avec le jugement lui-même.

Remplacé par : mon propre étiquetage d’incertitude. Quand je ne suis pas sûr qu’une chose est correcte, j’écris « CHECK: » devant. Quand j’en suis sûr, j’écris l’affirmation telle quelle. Ce système est binaire et honnête. Il ne coûte rien.

Les quatre ont été supprimées non pas parce qu’elles étaient en panne, mais parce qu’elles optimisaient l’efficacité à des endroits où l’efficacité n’était pas la contrainte limitante.

La règle de décision

Avant de construire une quelconque automatisation, je me pose une seule question :

Le goulot d’étranglement de cette tâche est-il le temps qu’elle prend, ou le jugement qu’elle exige ?

Si la réponse est le temps, l’automatisation mérite d’être envisagée.

Si la réponse est le jugement, l’automatisation mérite d’être évitée, ou du moins l’étape qui contient le jugement devrait être la seule chose que l’automatisation ne touche pas.

Trois sous-vérifications en découlent :

Sous-vérification une : à quoi ressemble l’échec, et à quelle vitesse remonte-t-il à la surface ? Certains échecs sont évidents et rapides : l’automatisation casse, plus rien ne fonctionne, vous le remarquez immédiatement. D’autres sont invisibles et lents : l’automatisation continue de tourner, produit un résultat plausible, et dégrade la qualité pendant des semaines. Les seconds sont pires. Avant de construire, je me demande : si cette automatisation produit silencieusement un mauvais résultat, combien de temps me faudra-t-il pour le remarquer ? Si la réponse est « plus d’une semaine », je veux un point de contrôle humain avant que le résultat soit utilisé, pas après.

Sous-vérification deux : est-ce que j’automatise la représentation du travail, ou le travail lui-même ? C’est la distinction la plus importante que j’aie trouvée, et il est facile de la manquer parce qu’un bon résultat d’IA a l’air d’un bon travail. Mettre en forme un brief, rédiger un résumé, structurer un document : ce sont des représentations de la réflexion, pas la réflexion elle-même. Les automatiser est peu risqué si la réflexion sous-jacente est la vôtre. Mais si l’automatisation produit la représentation avant que la réflexion ait eu lieu, vous obtenez quelque chose qui a l’air complet et qui ne l’est pas. L’automatisation que je devrais construire est celle qui met en forme le résultat après que j’ai fait le travail de jugement. Celle que je devrais éviter est celle qui produit le résultat à sa place.

Sous-vérification trois : cette tâche compose-t-elle ? Certaines activités gagnent en valeur à mesure qu’on les répète : on développe une reconnaissance de motifs, on construit une connaissance de la relation, on affine un modèle de la situation d’un client. Si vous automatisez une activité qui compose, vous arrêtez de composer. La machine fait les répétitions, pas vous. Sur un an, la différence est significative. Sur trois ans, c’est l’écart entre quelqu’un qui a une vision réellement approfondie de son domaine et quelqu’un qui a de bons outils. Je garde entre mes mains tout ce qui compose.

Ce que la règle autorise

Pour être clair : j’automatise beaucoup de choses. Cette règle ne produit pas un sceptique qui fait tout à la main. Elle produit une précision sur l’endroit où va l’automatisation.

J’automatise le formatage et la structure. J’automatise la compression de matière que j’ai déjà curée et annotée. J’automatise la récupération : je construis des systèmes qui font remonter la réflexion passée à la demande. J’automatise la planification et le routage : la couche administrative de tout workflow qui consiste purement à déplacer des choses d’un endroit à un autre.

Je n’automatise pas la première articulation de ma position sur quoi que ce soit. Je n’automatise pas la gestion des relations. Je n’automatise pas l’étape qui exige que je décide de ce qui compte. Et je n’automatise rien où le mode d’échec est une erreur au ton confiant, parce que ce mode d’échec est invisible jusqu’à ce qu’il ne le soit plus.

La question n’est jamais « est-ce que ceci peut être automatisé ? ». C’est « quel est le coût réel si ceci produit une réponse plausible mais fausse, et qui le remarque ? ».

Le document que je tiens

Je tiens un document court, un journal de décisions, où je consigne chaque automatisation que j’ai envisagée et que je n’ai pas construite, et pourquoi. Il compte environ deux douzaines d’entrées. C’est, sincèrement, plus utile que la liste des automatisations que je fais tourner, parce que les entrées contiennent le raisonnement expliquant pourquoi telle tâche relève du jugement, et ce raisonnement se transpose à de nouvelles décisions. Chaque fois que je suis tenté de construire quelque chose pour une tâche similaire, je consulte d’abord le journal.

La décision de ne pas automatiser est aussi délibérée que la décision d’automatiser. Prenez-la exprès, documentez-la, et elle cesse d’être une occasion manquée. Elle devient une politique.

Ce document, la matrice de décision d’outils et le format de journal de décisions que j’utilise, est disponible sous forme de modèle. La logique du formulaire est la même que celle décrite ici ; le modèle la rend réutilisable pour des décisions récurrentes.

→ Tool Decision Framework : 39 $. Matrice de décision structurée + journal de décisions. À déposer dans Obsidian ou Notion. (Envoi d’abord à la liste de la newsletter ; inscrivez-vous ci-dessous.)

Quatre automatisations supprimées. Chacune a enseigné quelque chose que la communauté du « construis d’abord » ne dit jamais tout haut : la question n’est pas de savoir si vous pouvez l’automatiser. C’est de savoir si, dans deux mois, vous serez content de l’avoir fait.

Prochain dans Systems → Comment je garde les résultats de l’IA honnêtes : les vérifications que j’applique avant qu’un livrable parte chez un client.