Audit IA — quelle méthode pour identifier skills et agents ?

Idée initiale

S'appuyer sur le lean (et plus largement la gestion par processus / BPM) pour cartographier l'existant et identifier les tâches candidates à un skill ou à un agent.

Pourquoi on écarte le lean

Le lean est un outil d'optimisation incrémentale d'un flux donné. Mal adapté à un audit IA pour 4 raisons :

Il optimise au lieu de redéfinir. Le lean enlève le gaspillage du flux ; l'IA permet souvent de supprimer le flux entier. Risque de paver la cowpath — automatiser des étapes qui ne devraient plus exister.
Il rate le tacite. Les value stream maps décrivent le happy path. Les meilleurs candidats IA sont dans les exceptions, le jugement, la mise en contexte — invisibles dans une VSM.
Mauvaise grille de tri. Le lean trie par temps × fréquence × gaspillage. Pour l'IA, les bons axes sont : variance des inputs, vérifiabilité de l'output, coût d'erreur, charge cognitive vs mécanique.
Coût d'opportunité. Un audit lean prend des semaines, et reste muet sur ce qu'on ne fait pas encore mais qu'on pourrait faire avec l'IA — son angle mort total.

Et la gestion par processus (BPM) ?

À distinguer du lean. Le BPM n'est pas une méthode d'optimisation, c'est une cartographie macro de l'entreprise : qui fait quoi, dans quel ordre, avec quels handoffs, sous quels indicateurs. Verdict nuancé :

Ce qu'on garde du BPM :

Carte d'ensemble utile pour situer où un agent peut s'insérer dans une chaîne de valeur — sans cette vue, on optimise des silos.
Handoffs et attentes entre services = signal fort de friction et de double saisie, donc de candidats IA évidents (résumés, transferts d'info, contrôles).
Référentiel partagé indispensable pour parler le même langage en Codir et arbitrer.

Ce qu'on rejette comme grille d'audit IA :

Découpage séquentiel et standardisé par nature — masque la variance, qui est précisément le signal qui distingue skill / workflow / agent.
Logique de propriétaire de processus — pousse à automatiser dans le périmètre existant au lieu de questionner la frontière entre rôles.
Niveau de granularité trop élevé — un processus BPM décrit « traiter une demande client », pas la dizaine de micro-décisions où l'IA est utile.
Comme le lean, ne dit rien des opportunités émergentes (ce qui n'est pas dans le processus aujourd'hui).

Conclusion : le BPM est utile en amont comme carte (où regarder), pas comme méthode d'identification. On l'utilise pour localiser les zones, pas pour qualifier les candidats.

Méthode proposée

Quatre entrées combinées, par ordre d'utilité décroissante :

Partir de la douleur. Où les gens râlent, où le travail s'accumule, où on rate des choses. Signal le plus fiable.
Partir des outcomes / JTBD. Quel résultat je veux produire, et quelle est la chaîne de raisonnement minimale pour y arriver ?
Partir de la donnée. Qu'est-ce qui est déjà structuré, numérique, accessible ? L'IA bute sur les inputs, pas sur le raisonnement.
Carte BPM en support. Pour situer ces trois entrées dans la chaîne de valeur et arbitrer en Codir.

Puis classer chaque candidat selon une grille :

Axe	Faible → Fort	Implication
Variance des inputs	faible → forte	code déterministe → workflow → agent
Vérifiabilité de l'output	forte → faible	autonome → humain dans la boucle
Coût d'erreur	faible → fort	shadow run direct → pilote contrôlé
Charge cognitive vs mécanique	mécanique → cognitive	skill simple → assistance experte

Et toujours conserver l'option « ne pas automatiser » — pour les moments d'apprentissage, de jugement, ou de relation.

Validation empirique

Shadow run sur 2-3 zones de douleur : faire tourner l'IA en parallèle pendant 2 semaines, comparer. Empirique > théorique. C'est ce qui tranche entre une bonne idée et une vraie opportunité.

À faire

Identifier 2-3 zones de douleur concrètes (commencer par DSI et management ?)
Récupérer la cartographie BPM existante si elle existe, sinon ne pas la construire pour l'audit
Construire la grille variance × vérifiabilité × coût × cognitif
Lancer un shadow run pilote

4.4 KiB Raw Permalink Blame History Unescape Escape