L'erreur la plus fréquente n'est pas de mal automatiser. C'est d'automatiser ce qui ne le méritait pas — et de découvrir un an plus tard qu'on entretient une mécanique qui coûte plus qu'elle ne rapporte.
Le réflexe naturel est de partir de ce qui agace. C'est un mauvais critère : ce qui agace occupe toute la place mentale, indépendamment de ce que ça coûte réellement. Voici une grille plus fiable.
Les quatre questions
Combien de fois par semaine ? En dessous de quelques occurrences hebdomadaires, l'automatisation se rentabilise rarement. Comptez, ne devinez pas : l'écart entre les deux est systématiquement surprenant.
Est-ce que ça se déroule toujours pareil ? Une tâche stable est automatisable. Une tâche dont chaque occurrence est un cas particulier ne l'est pas — vous passerez plus de temps à gérer les exceptions qu'à faire le travail.
Est-ce que quelqu'un attend pendant ce temps ? Une tâche qui bloque quelqu'un d'autre — un client, un collègue — vaut plus que sa durée brute. Le coût réel inclut l'attente qu'elle provoque en aval.
Est-ce que le processus est bon ? La question qui décide vraiment. Si le processus lui-même est mal fichu, l'automatiser revient à payer pour exécuter plus vite quelque chose qu'il fallait supprimer.
La règle de décision
Croisez la fréquence et la stabilité.
Fréquent et stable : automatisez, c'est le terrain naturel.
Fréquent et instable : ne l'automatisez pas encore. Stabilisez d'abord — souvent, l'instabilité vient d'un manque de règle plutôt que d'une vraie diversité des cas. Une fois la règle posée, revenez.
Rare et stable : documentez plutôt qu'automatiser. Une procédure écrite coûte une heure et ne se maintient pas.
Rare et instable : laissez tranquille. C'est du travail humain, et c'est très bien.
Les trois cas où il vaut mieux s'abstenir
Quand l'étape ne devrait pas exister. Une validation que personne ne lit, un tableau que personne n'ouvre, une confirmation qui double une autre confirmation. Supprimez au lieu d'automatiser. C'est le gain le plus rentable qui existe : il est immédiat et il ne se maintient pas.
Quand personne ne s'en occupera après. Une automatisation vit : les process changent, les outils se mettent à jour, les cas particuliers apparaissent. Si personne n'est identifié pour la faire vivre, elle se dégradera en silence — et une mécanique dégradée à laquelle on fait encore confiance est plus dangereuse que pas de mécanique du tout.
Quand l'erreur coûte cher et n'est pas détectable. Certaines tâches tolèrent mal l'automatisation parce qu'une erreur y passe inaperçue et se propage. Avant d'automatiser, demandez toujours : si ça se trompe, est-ce qu'on le voit ? Si la réponse est non, ajoutez un point de contrôle humain ou renoncez.
Et l'IA, dans tout ça ?
L'automatisation classique et l'IA ne répondent pas à la même question, et on les confond souvent.
L'automatisation exécute une règle. Si ceci, alors cela. Elle est prévisible, vérifiable, peu coûteuse à maintenir. C'est le bon choix chaque fois que la règle peut s'écrire.
L'IA traite ce qui ne s'écrit pas en règles : comprendre une demande formulée en langage naturel, résumer, classer selon des critères flous, rédiger un premier jet. Elle est plus puissante et moins prévisible — ce qui veut dire qu'elle demande un contrôle plus attentif.
La bonne question n'est donc pas « est-ce qu'on met de l'IA », mais « est-ce que cette tâche s'écrit en règles ». Si oui, une automatisation simple suffira, coûtera moins cher et cassera moins souvent. Beaucoup de projets présentés comme des projets IA sont en réalité des projets d'organisation, avec un peu d'automatisation classique au bout.
Par où commencer
Prenez vos cinq tâches les plus fréquentes. Passez-les dans la grille. Une seule ressortira comme évidente — c'est celle-là qu'il faut traiter, jusqu'au bout, avant de regarder les autres.
Une transformation réussie, ce n'est pas huit chantiers ouverts. C'est un chantier terminé, dont le résultat donne envie de faire le suivant.