Ce que contient un AI Workflow Design par service : l'anatomie d'un playbook

Quand une PME évalue la voie du playbook — une méthode d'adoption de l'IA déjà construite, à greffer dans les processus, plutôt qu'un conseil reconstruit à chaque fois — la question concrète arrive immanquablement : mais à l'intérieur, qu'y a-t-il vraiment ? C'est la bonne question. La différence entre un playbook qui fait avancer l'entreprise et un dossier de slides tient entièrement à sa structure, et cette structure est étonnamment reconnaissable : les playbooks d'adoption de l'IA sérieux, ceux que publient les organisations qui utilisent l'IA à grande échelle, partagent les mêmes ossatures. Qui les connaît sait distinguer en dix minutes un artefact pensé pour durer d'un artefact pensé pour la signature.

Il vaut la peine d'en démonter l'anatomie, car c'est aussi la manière la plus honnête de raconter ce que nous livrons quand nous parlons d'« un AI Workflow Design par service ». Ce n'est pas un terme de marketing : c'est un format avec des parties, et chaque partie répond à une question précise qu'une PME devrait exiger de voir résolue.

Deux axes, avant tout contenu

Chaque playbook d'adoption de l'IA, sous les différences de surface, s'organise le long de deux axes orthogonaux. Les reconnaître est le premier outil pour juger ce qu'on vous met sous les yeux.

• L'axe de navigation — comment vous trouvez « ce qui me concerne ». Les deux choix répandus sont par service/rôle (ventes, marketing, operations, administration, RH…) ou bien par phase (pilote → montée en charge → gestion continue). Ils ne s'excluent pas : les meilleurs formats utilisent le service comme porte d'entrée et la phase comme étiquette interne.
• L'axe de profondeur — si et comment le playbook vous situe avant de vous montrer les contenus. À un extrême, un modèle de maturité (en général cinq niveaux, avec un score par capacité) qui vous dit où vous en êtes ; à l'autre, un catalogue plat que vous parcourez librement. Le choix n'est pas affaire de goût : il change qui le playbook parvient à servir.

En gardant ces deux axes à l'esprit, les deux exemples publics les plus instructifs montrent des combinaisons opposées — et couvrent ensemble presque tout ce qu'une PME devrait s'attendre à trouver à l'intérieur.

Modèle A — le playbook « par piliers et phases » (l'exemple de GitHub)

GitHub a rendu public son propre playbook interne pour construire une main-d'œuvre augmentée par l'IA. C'est l'archétype du format parcourable par phase, et il est utile parce qu'il est pensé pour faire adopter, pas pour impressionner. Trois parties méritent l'attention, parce que ce sont exactement celles qu'une PME devrait retrouver, à échelle réduite, dans son propre playbook.

• Huit piliers fondateurs. Non pas des cas d'usage, mais les conditions pour que les cas d'usage prennent racine : sponsorship de la direction, une personne clairement responsable (un référent, pas un comité), politiques et garde-fous écrits, formation, métriques, les « promoteurs » internes qui diffusent l'usage par le bas, les bons outils, les communautés de pratique. C'est la partie qu'un playbook faible saute — et c'est la raison pour laquelle ses cas d'usage ne prennent ensuite pas racine.
• Un déploiement en trois phases, avec un horizon à chaque phase. 30 premiers jours = fondations (sponsor, référent nommé, politique d'usage en brouillon, métriques instrumentées). 90 premiers jours = élan (programme de promoteurs, communauté de pratique, hub de ressources, premiers cas de succès). Puis, en continu = montée en charge (former les formateurs, tableau de bord de retour). Un playbook avec un quand à côté de chaque « quoi » est pensé pour être exécuté ; un playbook sans échéances est pensé pour être lu.
• Deux mécaniques réutilisables. Un système d'outils à niveaux — validés (approuvés) contre admis mais pas encore validés — pour que les personnes sachent ce qu'elles peuvent utiliser sans demander à chaque fois ; et un entonnoir de métriques à trois étages : d'abord l'ampleur de l'adoption (combien l'utilisent), puis la profondeur de l'usage (combien et comment), enfin la corrélation avec un résultat business. Mesurer le dernier étage sans les deux premiers est la manière la plus courante de se raconter un ROI qui n'existe pas.

Modèle B — le playbook « par niveaux de maturité » (l'exemple de Microsoft)

Microsoft publie un modèle de maturité pour l'adoption de l'IA agentique : plus lourd que la navigation libre, et précisément pour cela un bon réservoir pour les parties de gouvernance et clarté des rôles qu'un playbook self-serve tend à laisser minces. Deux éléments valent comme modèles.

• Cinq piliers, cinq niveaux chacun. Stratégie et culture, refonte des processus et réalisation de la valeur, gouvernance et sécurité, technologie et données, organisation et personnes — chacun lu sur une échelle de maturité. Le point non évident : une entreprise se situe à des niveaux différents sur des piliers différents en même temps. C'est déjà la forme de l'AI-readiness — une moyenne unique « on est à 6 » cache plus qu'elle ne révèle.
• La répartition des rôles d'un Centre d'Excellence. Le modèle explicite qui possède quoi en cinq fonctions : collecte et priorisation des idées ; modèle opérationnel et droits de décision (ce qui est géré au centre et ce qui l'est par les services) ; activation et communauté ; standards et réutilisation (schémas, modèles, garde-fous) ; signaux d'adoption et de valeur. C'est le modèle prêt pour la case « contrôles de gouvernance » qu'un bon playbook rattache à chaque workflow.

Le modèle de Microsoft est calibré sur la grande entreprise : un Centre d'Excellence entier est hors d'échelle pour une PME. Mais les cinq fonctions de responsabilité, non — elles restent toutes nécessaires. Le vrai travail, pour une petite entreprise, n'est pas de les réduire : c'est de les comprimer dans une ou deux personnes qui les couvrent réellement. Le nombre de têtes change ; la liste des choses dont quelqu'un doit répondre, non.

Le squelette que nous recommandons à une PME

Une fois les deux modèles réunis et pesés à l'aune de la réalité d'une petite entreprise — où un processus lourd de Centre d'Excellence contredirait la promesse d'une adoption légère — le squelette que nous livrons a cinq parties. C'est ici que l'« AI Workflow Design par service » cesse d'être un slogan et devient un sommaire.

• Navigation primaire par service. C'est la porte d'entrée : vous ouvrez votre service — ventes, marketing, operations, administration et finance — et vous trouvez les cas d'usage qui vous concernent, pas un catalogue générique à filtrer à la main.
• Une étiquette de phase sur chaque entrée. Pilote, montée en charge, gestion continue : ainsi celui qui est déjà à mi-parcours filtre sur « ce qui vient après » au lieu de relire les pilotes qu'il a déjà menés à bien. C'est la mécanique des phases du Modèle A, appliquée à l'entrée individuelle.
• Aucun verrou de maturité sur l'accès aux contenus. Le playbook reste parcourable — on ne vous refuse pas la lecture tant que vous ne « méritez » pas un niveau. Mais votre score d' AI-readiness apparaît comme conseil non bloquant : « ouvrez d'abord ce service ». La maturité comme signal de recommandation, pas comme paywall.
• Un « responsable IA » d'une ou deux personnes, avec cinq fonctions à couvrir. Les cinq fonctions du Centre d'Excellence — collecte d'idées, droits de décision, activation, standards et réutilisation, signaux de valeur — deviennent une liste de contrôle pour cette ou ces deux personnes. On garde la rigueur, on laisse tomber l'hypothèse d'effectif qu'une PME n'a pas.
• Un bloc de gouvernance rattaché à chaque workflow. Niveau de risque, analyse d'impact, contrôles, humain dans le processus, surveillance : non pas une formalité en aval mais une partie de la conception. C'est l'overlay de conformité que nous décrivons à part — et la raison pour laquelle, quand nous concevons un workflow, la conformité n'arrive pas après.

Il y a une partie finale qui distingue un playbook utilisable d'un beau document : le format de livraison. La source de vérité reste un texte structuré — lisible, versionnable, que l'on peut mettre à jour quand l'outil change — mais pour être vraiment utilisé, chaque entrée de service a besoin d'un asset visuel léger à côté de la prose. Un playbook qui vit uniquement en PDF finit dans un dossier ; un playbook pensé pour être adopté vous met aussi en main comment le montrer à l'équipe.

À quoi sert de connaître l'anatomie

La raison pratique de démonter cette structure n'est pas académique. Que vous choisissiez de construire un playbook en interne, d'en acheter un prêt à l'emploi ou de vous faire accompagner, vous avez désormais le sommaire avec lequel juger la proposition qui vous arrive : a-t-elle une porte d'entrée par service ? met-elle une phase à côté de chaque cas d'usage ? dit-elle qui répond de quoi ? rattache-t-elle la gouvernance au workflow ou la renvoie-t-elle à plus tard ? peut-on la mettre à jour, ou est-elle figée dans une slide ? Ce sont cinq questions, et un artefact sérieux les tient toutes.

C'est aussi, pour être transparents, la forme de ce que nous greffons : un playbook déjà construit le long de ce squelette, adapté à votre service et porté en production. Le premier pas, cependant, vient avant le playbook et il est gratuit — savoir d'où partir. Notre évaluation d'AI-readiness vous donne en deux minutes une idée du service qui est prêt et avec quels contrôles autour ; et si vous voulez comprendre comment on passe de ce sommaire à un workflow qui tourne, nous avons ici comparé les trois voies — cours, consultant, playbook — ou bien nous en parlons, sans engagement.

Cet article a une visée d'orientation. Les formats cités proviennent de playbooks et de modèles de maturité publics de GitHub et de Microsoft ainsi que d'analyses sectorielles : ce sont des modèles de référence, pas des prescriptions valables pour toute entreprise. Structure, phases et rôles doivent toujours être adaptés à la dimension, aux données et au contexte de chaque entreprise.