Le premier processus à automatiser n'est pas le plus visible

Beaucoup d'entreprises choisissent leur premier cas d'usage IA au bruit qu'il fait : le plus visible, le plus demandé, le plus facile à montrer. Je propose un autre critère de départ : le premier processus à traiter est celui qui passe six tests, dans cet ordre de lecture, et dont on a d'abord redessiné le travail.

Bonjour,

La norme, quand une direction décide d'« industrialiser l'IA » : on dresse la liste des idées, on garde celle qui impressionne le plus au comité, et on la confie à une équipe projet. Et puis, six mois plus tard, le démonstrateur tourne, mais le processus, lui, n'a pas bougé : mêmes étapes, mêmes validations, mêmes files d'attente, avec une fenêtre de chat en plus.

Ma proposition tient en deux idées. La première : on ne choisit pas le premier processus à la visibilité, on le choisit à six critères qui disent s'il est automatisable maintenant. La seconde : on ne branche pas un outil sur un processus que l'on n'a pas relu. On le redessine d'abord.

Pourquoi redessiner avant d'outiller

Le McKinsey State of AI 2026, publié le 25 août 2026, est une enquête auprès de dirigeants : c'est une estimation de dirigeants, pas une mesure comptable. Il relève qu'environ trois quarts des hauts performeurs ont redessiné leurs workflows, contre environ un quart des autres (McKinsey, State of AI). Les hauts performeurs sont ici ceux que l'étude désigne ainsi. Le chiffre ne prouve pas que redessiner cause la performance. Il dit que les deux vont ensemble, de façon assez nette pour qu'on s'en serve comme point de départ.

Le Work Trend Index de Microsoft, publié le 5 mai 2026, va dans le même sens. Il repose sur ce que déclarent des salariés, donc c'est une estimation de salariés. Les facteurs organisationnels y pèsent 67 % de l'impact déclaré, contre 32 % pour les facteurs individuels (Microsoft, Work Trend Index). Autrement dit, les répondants attribuent environ deux fois plus d'impact à l'organisation du travail qu'aux facteurs individuels, avec les limites d'une enquête déclarative.

Deux sources, deux populations, et aucune ne dit comment choisir. Elles disent où chercher : dans le travail lui-même, pas dans le catalogue d'outils.

Les six critères

Une précaution d'abord. Ce qui suit est une grille Unlockers. Je ne m'appuie sur aucune étude externe qui la validerait : je n'ai pas trouvé de source récente qui établisse ces six critères. C'est une grille de travail, construite pour être discutée et contredite. Chaque critère répond à une question simple, que vous pouvez poser à l'équipe qui porte le processus.

1. Le volume. Le processus se répète-t-il assez souvent pour que le gain compte ? Un processus rare, même pénible, ne rembourse pas l'effort de le reconstruire. Un processus traité tous les jours par plusieurs personnes, si. Question : combien de fois par semaine, par combien de personnes ?

2. Les règles explicitables. Pouvez-vous écrire comment la décision se prend, avec ses cas courants et ses exceptions ? Si l'expert répond « ça dépend, je le sens », le processus n'est pas prêt : il faut d'abord rendre le savoir lisible. Si la réponse tient sur une page, avec des exceptions connues, c'est un bon signe. Question : un nouvel arrivant pourrait-il suivre la règle écrite ?

3. Les données accessibles. Les informations nécessaires sont-elles disponibles, à jour, et utilisables légalement par un outil ? Un processus dont les données sont dans des pièces jointes, des tableurs personnels ou des boîtes mail est un processus dont l'accès est le vrai chantier. Question : où se trouvent les données, et qui a le droit de les ouvrir ?

4. Le délai client. Le temps de traitement est-il ressenti par le client, interne ou externe ? Un délai qui ne gêne personne ne motive personne. Un délai qui retarde une facturation, une livraison ou une réponse à un client donne une raison claire d'agir, et une mesure facile : le temps avant, le temps après. Question : qui attend, et combien de temps ?

5. Le coût d'erreur. Que coûte une erreur, et peut-on la rattraper ? Un brouillon relu par un humain avant envoi n'a pas le même risque qu'une décision exécutée seule. Plus le coût d'erreur est élevé, plus il faut de contrôle, de traçabilité et de temps de mise en route. Question : si la machine se trompe, qui le voit, quand, et que perd-on ?

6. Le gain attendu. Qu'espérez-vous y gagner, en heures ou en euros ? Sans hypothèse de gain, impossible de savoir si le chantier se rembourse, ni de juger le résultat après coup. Une estimation grossière suffit au départ : temps gagné par traitement, multiplié par le volume, ou erreurs évitées. Question : qu'espérez-vous gagner en intégrant l'IA sur ce processus, et comment le mesurerez-vous ?

Comment lire la grille

Les six critères ne s'additionnent pas comme des points. Ils se lisent comme des feux. Un volume élevé et un délai client sensible disent que le sujet vaut la peine. Des règles explicitables et des données accessibles disent qu'il est faisable maintenant. Le coût d'erreur dit à quelle vitesse et avec quel contrôle avancer. Le gain attendu dit si le jeu en vaut la peine : sans estimation en heures ou en euros, on ne saura pas si le résultat est au rendez-vous.

Un exemple de lecture, construit pour l'illustration et qui ne décrit aucun client. Imaginez deux processus candidats. Le premier est très visible : il fait l'objet de réunions, tout le monde en parle, mais ses règles dépendent de l'avis de deux experts et ses données sont dispersées. Le second est discret : il se répète chaque jour, ses règles tiennent sur une page, ses données sont dans un seul système, et un retard fait attendre un client. Le premier gagne le comité. Le second passe les six critères. C'est lui le premier.

Le piège inverse existe aussi. Un processus qui passe cinq critères sur six mais échoue sur le coût d'erreur n'est pas à écarter : il demande un humain dans la boucle, c'est-à-dire un point de contrôle prévu dès le départ, pas ajouté après un incident.

Redessiner : ce que cela veut dire concrètement

Redessiner n'est pas faire un schéma de plus. C'est répondre à trois questions avant d'ouvrir un outil. Quelles étapes existent uniquement parce que l'information circulait mal, ou parce qu'une personne devait la ressaisir ? Quelles validations ne changent jamais le résultat ? Quelle décision relève vraiment d'un jugement, et laquelle applique seulement une règle ?

Cette relecture produit souvent un résultat avant même l'outil : des étapes supprimées, des validations déplacées, des règles écrites. L'outil vient ensuite sur un travail plus simple, donc plus facile à mesurer.

Deux repères, avec leurs limites

Je cite deux éléments qui éclairent la question, en précisant leur portée.

Le premier est un cas. Selon The Pragmatic Engineer du 8 octobre 2026, chez Ramp, une équipe de quatre personnes a construit une plateforme interne d'applications. C'est un cas isolé : il montre qu'une petite équipe peut le faire, il ne dit pas que toute équipe le peut, ni dans quel délai ni à quelle qualité. Je le cite comme une illustration, pas comme un chiffre de marché.

Le second est une opinion. Dans son état de l'industrie du 6 octobre 2026, The Pragmatic Engineer juge que, dans beaucoup d'entreprises, la revue humaine du code est du « théâtre ». C'est le point de vue de son auteur, pas une mesure. Je le retiens pour la question qu'il pose, valable bien au-delà du code : dans vos processus, quelles validations protègent vraiment, et lesquelles rassurent seulement ? Cette question rejoint le cinquième critère. Un contrôle qui ne change jamais rien est un coût sans protection. Un contrôle absent là où l'erreur coûte cher est un risque sans filet.

Trois points à retenir

• Choisir au test, pas au bruit. Six critères (volume, règles explicitables, données accessibles, délai client, coût d'erreur, gain attendu) donnent une raison défendable au comité. Cette grille est celle d'Unlockers, sans validation externe.
• Redessiner avant d'outiller. D'après McKinsey (25 août 2026, estimation de dirigeants), environ trois quarts des hauts performeurs l'ont fait, contre environ un quart des autres. Le lien n'est pas une preuve de causalité.
• Mesurer avant et après. Sans temps de traitement, volume et taux d'erreur relevés au départ, vous n'aurez que des impressions pour juger le résultat.

Questions à vous poser cette semaine

• Quel processus de votre direction se répète chaque jour, avec des règles que vous sauriez écrire sur une page ?
• Le premier cas d'usage de votre feuille de route a-t-il été choisi pour sa visibilité ou pour ses critères ?
• Savez-vous aujourd'hui combien de temps prend ce processus, et combien d'erreurs il produit ?
• Quelle validation de vos processus pourriez-vous retirer sans que le résultat change, et laquelle devez-vous ajouter ?

Si vous ne pouvez pas répondre à la troisième, il manque une mesure de départ. C'est le premier travail, avant tout outil.

Et maintenant ?

Répondez à cet email en me décrivant, en deux lignes, le processus que vous seriez tenté d'automatiser en premier. Je vous dirai quels critères il passe ou ne passe pas, et ce qu'il faudrait relever avant de commencer. Je lis tout et je réponds.

Si vous préférez avancer avec nous, le coaching Unlockers consiste à appliquer cette grille ensemble, sur vos propres processus, avec les personnes qui les connaissent. Pour en parler : contact@unlockers.ai

À bientôt,

Jean Dupuis, Unlockers.ai