Le leadership l'IA, c'est le leadership des workflows : maîtrisez les handoffs

J’ai vu le même schéma se répéter dans les usines, les objets connectés, le SaaS et la fintech : la technologie est rarement le goulot d’étranglement. Ce sont les handoffs.

Avec l’IA, cela saute aux yeux. Un modèle peut être impressionnant et ne générer aucune valeur pour l’activité si le workflow autour de lui est flou. Qui fournit les inputs ? Qui valide l’output ? Que se passe-t-il en cas d’exception ? Qui rend des comptes quand ça échoue ? Quand ces réponses restent imprécises, le « projet IA » se transforme en pilote permanent.

Quand je dirigeais des organisations R&D couvrant l’embarqué, le cloud, l’électronique, la mécanique et la QA, j’ai retenu une règle simple : le résultat suit la responsabilité. Pas la motivation. Pas la densité de talent. La responsabilité. Or, à l’ère de l’IA, la responsabilité concerne surtout les workflows, et en particulier les zones grises entre équipes.

Voici ma conviction : le leadership IA est d’abord un leadership de workflow. Les équipes qui gagnent maîtrisent les handoffs.

Le malentendu : l’IA serait un outil qu’on saupoudre

La plupart des dirigeants cherchent à « ajouter de l’IA » comme on ajoute un dashboard. Ils choisissent un use case, financent un modèle et attendent que ça marche. Puis la réalité rattrape :

• Les données arrivent en retard, incomplètes ou incohérentes.
• Le business n’arrive pas à s’accorder sur ce que signifie « bon ».
• Le juridique ou la compliance sont sollicités à la fin.
• Les opérations découvrent que le modèle échoue précisément là où le processus est déjà fragile.
• Tout le monde accuse le modèle.

Dans l’automatisation industrielle, personne n’accepterait cela. Personne ne mettrait en production un bras robotisé sans préciser l’alimentation, les capteurs, les verrouillages de sécurité, le bac de rebut, le plan de maintenance et les instructions opérateur. L’IA mérite le même niveau d’exigence.

Le plus inconfortable est que le sujet n’est pas d’abord technologique. C’est un sujet de modèle opérationnel. La question « qui possède le workflow ? » décide si l’IA devient un levier ou un bruit de fond.

D’où vient réellement la valeur : la boucle fermée

Tout système d’IA qui produit des résultats mesurables a la même structure : une boucle fermée, avec une responsabilité explicite à chaque étape.

1. Contrat d’input : ce qui entre, d’où, dans quel format, avec quels contrôles qualité.
2. Point de décision : ce que l’IA a le droit de décider, de recommander ou de rédiger.
3. Validation et escalade : qui approuve, quand l’exécution peut être automatique, et quand il faut s’arrêter.
4. Traitement des exceptions : comment les cas limites sont routés, catégorisés et résolus.
5. Feedback : comment les résultats sont capturés pour que le système progresse, ou au minimum ne répète pas les mêmes erreurs.

S’il manque un seul de ces éléments, vous n’avez pas un produit d’IA. Vous avez une fonctionnalité, avec un profil de risque que vous ne maîtrisez pas.

C’est aussi la raison pour laquelle les équipes transverses gagnent. Pas par effet de mode, mais parce qu’un workflow traverse, par définition, des frontières : sales vers ops, ops vers finance, support vers engineering, compliance vers product. Si les handoffs ne sont pas pilotés, votre système d’IA héritera du pire de votre organigramme.

Les handoffs, c’est le produit

Quand j’étais CEO d’une business unit dans le smart building et la home automation, les échecs les plus coûteux venaient rarement d’un capteur ou du cloud. Ils venaient des interstices : entre product et manufacturing, entre manufacturing et fournisseurs, entre support et R&D. Les systèmes connectés rendent les handoffs visibles, car tout est traçable, y compris les délais, le rework et les jeux de blame.

L’IA fait la même chose, en accéléré. Elle amplifie ce que vous êtes déjà :

• Si vos inputs sont maîtrisés, l’IA renforce cette discipline.
• Si vos validations sont politiques, l’IA ouvre un nouveau champ de bataille.
• Si votre gestion des exceptions est au cas par cas, l’IA va créer un déluge de « cas spéciaux » et vos équipes vont saturer.

Je considère donc les handoffs comme un sujet de design produit. Pas comme du « change management ». Pas comme de la « formation ». Comme du design.

Cette approche irrigue aussi mes propres ventures. Quand je construis des produits comme Shopeno et IBHQ, l’objectif n’est pas d’impressionner avec l’IA. L’objectif est de retirer la friction d’un workflow complet : onboarding, vérification, opérations au quotidien, support et contrôle. Cela impose un autre type de leadership. Vous ne pouvez pas vous cacher derrière un modèle si le workflow casse pour un utilisateur réel à 7 h 30 un lundi.

Un modèle opérationnel pragmatique : un owner, une lane, un stop button

Si vous cherchez des gains d’output mesurables, je recommande un modèle opérationnel sans détour. Ce n’est pas le seul, mais c’est celui que j’ai vu tenir face au réel.

1) Nommez un owner de workflow, pas un « AI lead »

Choisissez un workflow qui compte (recouvrement, triage du support client, traitement des NCR fournisseurs, réclamations garantie, backlog grooming). Attribuez un owner unique, responsable du résultat de bout en bout.

Cette personne doit pouvoir coordonner plusieurs fonctions. Si elle ne peut pas influencer les inputs et les validations, elle échouera, et vous vous tromperez de diagnostic.

2) Définissez la lane : recommend, draft ou execute

Beaucoup de déploiements IA échouent parce que la lane est ambiguë. Rendez-la explicite :

• Recommend : l’IA propose, un humain décide. Idéal pour un premier déploiement.
• Draft : l’IA prépare le livrable (email, rapport, code, synthèse de dossier), un humain valide.
• Execute : l’IA agit automatiquement dans des limites et contrôles stricts.

Si vous ne savez pas dire clairement dans quelle lane vous êtes, vous oscillerez entre excès de confiance et excès de contrôle. Dans les deux cas, l’adoption s’effondre.

3) Concevez le chemin des exceptions avant de livrer

Les exceptions ne sont pas des cas marginaux. C’est la vraie charge. Le moyen le plus rapide de perdre en crédibilité consiste à déployer une IA qui marche « la plupart du temps », puis oblige vos meilleurs profils à rattraper les échecs à la main.

Définissez trois catégories :

• Exceptions connues (déjà comprises) : routage via des règles.
• Exceptions inconnues (nouveaux patterns) : routage vers des humains, avec un formulaire de capture.
• Actions interdites : hard stops. Pas de débat. Pas de « juste cette fois ».

C’est aussi ici que vous fixez votre vitesse d’apprentissage. Si les exceptions inconnues ne sont ni catégorisées ni réinjectées, vous payez des frais de scolarité sans devenir plus intelligent.

4) Mettez un stop button dans le workflow, pas dans une policy

Dans les usines et les lignes de production, on conçoit la sécurité dans le système. Ce n’est pas un slide deck. L’IA appelle la même logique. Vous avez besoin d’un mécanisme d’arrêt concret, utilisable par l’opérateur sans demander d’autorisation.

Ce stop button peut être aussi simple qu’un toggle, un seuil de confiance qui impose une revue humaine, ou une étape de validation si certaines conditions sont réunies. L’essentiel est qu’il soit réel, immédiat et sous responsabilité.

Si vous voulez une lecture plus « opérateur » de ce point, l’idée est directement liée à AI value isn’t in the org chart. It’s in the stop button.

5) Mesurez le throughput et le rework, pas les « heures économisées »

Les heures économisées sont une vanity metric : elles ignorent la qualité et les coûts en aval. En manufacturing, personne ne célèbre une ligne plus rapide si les défauts doublent. En travail intellectuel, avec l’IA, c’est la même histoire.

Suivez :

• Cycle time : du premier input à l’output validé.
• First pass yield : fréquence d’acceptation de l’output IA sans rework.
• Taux d’escalade et principales causes d’exception.
• Taux de défauts en aval (remboursements, réouvertures, alertes compliance, réclamations clients).

Cette logique prolonge l’argument développé dans Stop Measuring AI by Hours Saved. L’objectif n’est pas de travailler moins. L’objectif est de produire davantage de résultats corrects, à effort constant.

Un exemple vécu : ce que j’ai changé après des années de qualité industrielle

J’ai passé onze ans dans l’électronique de puissance et la qualité marché. Cet environnement vous apprend à respecter les modes de défaillance. Un drive peut fonctionner parfaitement au labo et échouer sur le terrain à cause de variations d’installation, de conditions environnementales, de tolérances fournisseur ou d’erreurs humaines. La solution n’est que rarement un effort héroïque d’ingénierie. C’est, le plus souvent, un système plus robuste : des specs plus claires, une meilleure couverture de test, des boucles de feedback plus solides et une responsabilité sans ambiguïté sur les actions correctives.

Plus tard, quand j’ai dirigé la R&D puis une business unit développant des capteurs connectés et des systèmes de contrôle bâtiment, j’ai appliqué cette même discipline au logiciel et à la donnée. Quand quelque chose cassait, la question n’était pas : « qui a codé ça ? ». C’était : « où le workflow a-t-il laissé passer de l’ambiguïté ? ». Définitions d’inputs. Frontières de responsabilité. Critères de validation. Handoff vers le support. Gates de release.

Les projets IA exigent exactement cette posture. Si vous considérez l’IA comme de l’automatisation, vous posez naturellement les bonnes questions : quelles tolérances, quel flux de rejet, qui est pagé, quel plan de containment, quel équivalent CAPA après une mauvaise décision.

C’est pour cela que je reviens toujours au leadership de workflow. C’est la seule forme de leadership IA qui passe à l’échelle.

Le prisme de décision que j’utilise aujourd’hui

Quand une équipe propose une initiative IA, je passe cinq questions. Si nous ne pouvons pas y répondre clairement, nous ne sommes pas prêts à livrer.

• Quelle est l’unité d’output que nous voulons augmenter (dossiers clôturés, devis envoyés, tickets résolus, factures rapprochées, commandes traitées) ?
• Qui possède le workflow de bout en bout, y compris les parties ingrates ?
• Quelle est la lane (recommend, draft, execute) et quels sont les hard stops ?
• Où vont les exceptions et comment deviennent-elles de l’apprentissage ?
• Quel KPI nous pénalisera pour le rework plutôt que de nous récompenser pour la seule vitesse ?

Si vous cherchez un complément plus technique à ce prisme opérationnel, il se combine bien avec AI Architecture Isn’t a Diagram. It’s an Operator’s Checklist.

Mon point de vue : les gagnants auront un style « peu romantique »

Les équipes qui gagneront avec l’IA ne seront pas celles qui font les démos les plus spectaculaires. Ce seront celles qui auront la fiabilité la plus ennuyeuse. Des inputs propres. Des validations explicites. Une gestion des exceptions conçue. De vrais mécanismes d’arrêt. Et un owner unique, comptable du throughput et de la qualité.

C’est cela, le leadership de workflow. Et c’est le style de leadership que l’ère de l’IA sélectionne.

Les modèles deviendront moins chers et plus performants. Vos handoffs, eux, ne se corrigeront pas tout seuls.

Prenez le contrôle du workflow. Prenez le contrôle des handoffs. Alors l’IA devient un avantage cumulatif, plutôt qu’une ligne de plus dans un budget d’innovation.