pkm/00-inbox/audit-ia-challenge-approche-lean.md
Philippe e3223ef191 S24
2026-06-10 23:15:41 +02:00

68 lines
4.4 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

---
date: 2026-06-02
tags: [ia, audit, methode, inbox]
statut: a-traiter
---
# 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 :
1. **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.
2. **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.
3. **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.
4. **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 :
1. **Partir de la douleur.** Où les gens râlent, où le travail s'accumule, où on rate des choses. Signal le plus fiable.
2. **Partir des outcomes / JTBD.** Quel résultat je veux produire, et quelle est la chaîne de raisonnement minimale pour y arriver ?
3. **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.
4. **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