Automatiser n’est pas innover

Dans les projets numériques, le mot innovation accompagne souvent une opération plus modeste : remplacer une étape humaine par un formulaire, un script ou un modèle. Cette opération peut être utile. Mais elle ne devient pas automatiquement une innovation parce qu’elle contient de l’IA.

À mes yeux, une innovation doit améliorer une situation complète : le temps de traitement, la compréhension, la qualité de la décision et la possibilité de corriger une erreur. Si elle réduit seulement le travail visible d’une équipe en augmentant le contrôle, la contestation ou la charge cachée, elle n’a fait que déplacer le problème.

La charge ne disparaît jamais

Un système automatisé crée souvent un travail moins visible : vérifier les exceptions, expliquer les résultats, corriger les données, traiter les recours et surveiller les alertes. Ce hidden work, ou travail caché, doit être mesuré dès le pilote.

Un chatbot qui répond à 80 % des demandes peut sembler performant. Si les 20 % restants sont les cas les plus complexes et arrivent à une équipe déjà réduite, le gain global peut être faible. Il faut donc étudier la distribution des cas, pas seulement la moyenne.

Une innovation doit laisser une porte de sortie

Je considère qu’un système responsable doit documenter un fallback, c’est-à-dire une procédure alternative lorsque le modèle est incertain, indisponible ou contesté. Le fallback peut être une revue humaine, une ancienne procédure ou un traitement temporairement manuel.

Cette porte de sortie n’est pas un aveu d’échec. Elle constitue une condition de confiance. Les équipes peuvent expérimenter plus sereinement lorsqu’elles savent comment arrêter le système, prévenir les personnes concernées et revenir à un fonctionnement antérieur.

Ce que je mesurerais avant de parler d’innovation

• le temps réellement gagné, y compris le temps de vérification ;
• le taux de décisions corrigées ou contestées ;
• la compréhension du résultat par les personnes concernées ;
• les écarts entre groupes ou contextes ;
• la capacité à désactiver le système sans perdre les dossiers en cours.

Ces indicateurs ne remplacent pas la qualité technique. Ils rappellent simplement qu’un modèle est une partie d’un service, pas le service lui-même.

Un scénario simple pour résister à l’effet de mode

Imaginons un service local qui automatise le tri initial de demandes. Avant le modèle, l’équipe devrait observer le parcours existant : où les personnes attendent-elles, quelles informations manquent, quelles erreurs reviennent et qui absorbe le travail invisible ?

Le pilote pourrait ensuite comparer trois versions : procédure actuelle, automatisation avec vérification humaine et automatisation plus rapide sans vérification. Si la troisième version augmente les recours ou oblige les agents à corriger davantage de dossiers, elle n’est pas nécessairement la plus innovante.

Cette méthode répond à une objection fréquente : « toute innovation comporte un risque ». Oui, mais un risque acceptable doit être limité, mesuré et réversible. L’enthousiasme technologique ne dispense pas de définir un success criterion, c’est-à-dire un critère de succès observable avant le déploiement.

L’innovation technologique devient crédible lorsqu’elle augmente la capacité d’agir des personnes. Sinon, elle peut être rapide, moderne et parfaitement optimisée — tout en rendant le système plus difficile à comprendre et à contester.