Diagnose. Prioritise. Adopt. Notre framework AI-Augmented Enterprise.

Diagnose. Ce que couvre l'audit de maturité IA.

La phase Diagnose regarde au-delà de la surface d'un programme IA et lit la réalité opérationnelle qui se trouve dessous. D'après notre expérience, la plupart des entreprises savent ce qu'elles ont fait en IA en comptant les proof-of-concept et les démos fournisseurs. Elles savent beaucoup moins ce qu'elles peuvent réellement délivrer, qui possède le travail après le lancement, où la donnée fait confiance, et à quoi ressemble l'exposition réglementaire sur l'ensemble des cas d'usage de la trajectoire. L'audit couvre quatre couches.

La couche capacité. Ce que les équipes engineering et data peuvent réellement construire. Les compétences sur le banc, l'outillage en place, les standards de plateforme qui existent déjà ou doivent être créés. Les équipes avec lesquelles nous travaillons ont souvent une capacité d'ingénierie plus forte qu'elles ne le réalisent, et une discipline de plateforme plus faible qu'elles ne le voudraient. Les deux méritent d'être nommées honnêtement.

La couche donnée. Où vit la donnée fiable, qui décide ce qu'est la source canonique, et quels sont les écarts entre la donnée qui existe et la donnée dont les AI agents auront besoin. Il s'agit rarement d'une question de volume. C'est presque toujours une question de gouvernance, et la phase Diagnose fait généralement émerger des désaccords non résolus sur la propriété qui auraient dû être tranchés avant le financement du premier cas d'usage.

La couche réglementaire. La cartographie des cas d'usage de la trajectoire face aux régimes réglementaires qui s'appliquent, dont l'AI Act pour l'exposition européenne, les régulateurs des services financiers lorsque pertinent, et les régimes nationaux de protection des données dans les régions où le travail s'exécutera. Mobiliser le juridique, la sécurité et la conformité dans Diagnose plutôt que dans un point d'audit final, c'est l'un des mouvements à plus fort effet de levier que nous recommandons.

La couche organisationnelle. Qui veut vraiment le programme IA au sein de l'équipe de direction, qui préférerait le statu quo, où se trouve réellement l'adhésion des opérateurs, et à quoi ressemble la politique du build une fois passé de l'innovation aux opérations. La lecture honnête de cette couche est le plus important prédicteur unique de la capacité du programme à atteindre la production.

L'audit n'est pas une démo fournisseur conduite par nos soins. C'est une conversation structurée avec l'équipe de direction, l'équipe engineering, les opérateurs, et les fonctions juridique et conformité, avec en sortie une cartographie lucide de l'endroit où se trouve l'organisation et où vivent les écarts. Les clients qui prennent Diagnose au sérieux entrent dans Prioritise avec une vue beaucoup plus nette de ce qui est réellement finançable.

Prioritise. L'exercice de scoring qui concentre le budget.

La phase Prioritise réduit une longue liste de cas d'usage IA plausibles à un petit nombre de paris qui justifient l'investissement. Les équipes avec lesquelles nous travaillons arrivent généralement avec quelque part entre quinze et quarante cas d'usage candidats, dont chacun sonne raisonnable décrit isolément. Le métier dans Prioritise est d'appliquer une discipline de scoring cohérente qui fait émerger les cas d'usage qui paieront en retour et ceux qui consommeraient un budget disproportionné pour une valeur marginale.

Le scoring que nous utilisons porte cinq dimensions, dont chacune est notée explicitement par l'équipe de direction avec un raisonnement, et pas seulement des chiffres. Les dimensions sont la valeur opérateur, la faisabilité technique, l'état de préparation des données, l'exposition réglementaire, et le coût de conduite du changement. Un cas d'usage qui obtient une note élevée sur la valeur opérateur mais basse sur l'état de préparation des données est un candidat dans lequel on investit différemment d'un cas qui obtient une note élevée sur la faisabilité technique mais basse sur la valeur opérateur. La lecture honnête du scoring tend à compresser la longue liste à entre trois et six paris que l'organisation peut réellement délivrer sur l'horizon pertinent.

D'après notre expérience, la phase Prioritise est celle où l'équipe de direction a finalement la conversation sur les arbitrages qu'elle a silencieusement évitée. Deux dirigeants veulent chacun voir leur cas d'usage priorisé, le budget en soutient un, et la discussion qui suit est celle qui aurait dû avoir lieu des mois plus tôt. La valeur du framework réside en partie dans le scoring et largement dans la conversation que le scoring force.

Pour approfondir la réflexion de priorisation qui sous-tend cette phase, nos écrits antérieurs sur le passage du proof-of-concept à la production couvrent le terrain opérationnel qui rend un cas d'usage priorisé réellement livrable. Les deux pièces fonctionnent ensemble : Prioritise vous dit quoi construire, la discipline de production vous dit comment vous assurer que cela part en production.

Adopt. Le travail de conduite du changement dont personne ne parle.

La phase Adopt est celle la plus souvent sautée et celle qui décide si le programme IA se transforme en valeur opérationnelle. Le motif que nous observons chez les équipes que nous conseillons est constant. La phase de build récolte le budget, l'attention du comité de pilotage et le communiqué de presse. La phase d'adoption récolte un petit plan de formation ajouté à la fin. Les agents partent en production, les opérateurs ne les utilisent pas, et trois trimestres plus tard, le programme est en train d'être discrètement renommé.

L'adoption est un travail de conception, pas de formation. Le métier consiste à mettre les opérateurs dans la salle dès le premier sprint, les laisser façonner ce que fait l'agent, ce qu'il montre, quand il les interrompt et comment il reconnaît son incertitude. Les agents que les opérateurs co-conçoivent sont les agents qu'ils utilisent. Les agents que les opérateurs découvrent au lancement sont les agents qu'ils évitent. Nous avons vu ce scénario se rejouer suffisamment de fois pour insister désormais sur la participation des opérateurs en phase de conception comme préalable à notre mission, et non comme une option.

L'adoption exige aussi une discipline de passation explicite. L'équipe d'opérations qui exploitera l'agent après le lancement doit se trouver dans la salle avant que l'agent n'existe. Elle écrit le runbook avec l'équipe de build. Elle co-conçoit l'alerting. Elle nomme la rotation d'astreinte. Elle définit le service level agreement. Le jour du lancement, l'agent leur appartient déjà. Les programmes qui tiennent cette discipline gardent généralement leurs agents en production. Les programmes qui traitent la passation comme l'étape finale reconstruisent généralement la mission six mois plus tard.

La troisième dimension d'Adopt, c'est la couche incitative. Des opérateurs dont la performance est mesurée selon des indicateurs que l'agent n'aide pas, voire qu'il entrave activement, n'utiliseront pas l'agent quelle que soit la qualité de la conception. La phase Adopt regarde honnêtement le système de mesure et d'incitation qui entourera l'agent dans son usage quotidien, et fait émerger les changements qui doivent se produire en parallèle du build technique.

Un programme IA qui livre des agents et n'atteint jamais les opérateurs est un programme qui a fait la moitié facile du travail. L'adoption est l'endroit où vit la valeur, et elle ne cède pas à l'accélération.

Comment AI-Augmented Enterprise s'intègre à la Tech Factory.

AI-Augmented Enterprise est le côté conseil du travail. Le côté build, quand les cas d'usage priorisés exigent de l'engineering et que les agents doivent être construits, passe par notre Tech Factory. L'intégration entre les deux côtés est l'un des choix opératoires que nous avons faits délibérément, et c'est l'une des raisons pour lesquelles les clients travaillent avec nous à travers les deux moteurs plutôt que de les séparer.

L'intégration compte parce que l'intention de conception qui sort de Prioritise doit survivre au build. L'équipe de build doit comprendre pourquoi un cas d'usage a été choisi, quels arbitrages ont été acceptés, à quoi ressemble le plan d'inclusion des opérateurs, et quels sont les engagements de gouvernance. Quand le partner conseil qui a piloté Prioritise reste proche de l'équipe Tech Factory qui conduit le build, l'intention de conception tient. Quand la mission est passée à une équipe d'ingénierie inconnue, la dérive commence dès le premier sprint et tend à se composer.

En pratique, voici comment nous conduisons cela : le partner conseil d'AI-Augmented Enterprise siège au comité de pilotage du build tout au long de la mission. Il ne pilote pas l'engineering. Il tient l'intention de conception et rattrape la dérive. Le partner Tech Factory pilote le build, le partner conseil tient le brief, et l'équipe client conserve l'autorité d'intégration. Ce triangle est le modèle opératoire qui, d'après notre constat, livre généralement des agents qui fonctionnent.

La différence entre pilotes et production.

Si votre organisation porte un portefeuille de pilotes IA qui n'ont pas fait le saut vers la production, la phase Diagnose vous dira généralement pourquoi avant qu'aucun nouveau cas d'usage ne soit ajouté à la trajectoire. Le motif honnête, que nous avons exploré dans nos écrits antérieurs sur l'industrialisation des AI agents, c'est que le goulot d'étranglement est rarement le modèle. C'est la discipline opérationnelle autour du modèle, la confiance dans la donnée qui se trouve en dessous, et l'inclusion des opérateurs qui aurait dû avoir lieu avant que le build ne commence.

AI-Augmented Enterprise est le framework qui adresse ces trois fondations explicitement. Il ne promet pas des pilotes plus rapides. Il promet un plus petit nombre de paris mieux choisis, avec le modèle opératoire en place pour les transformer en systèmes en production que les opérateurs utilisent réellement. Les clients qui ont parcouru le framework avec nous en sortent généralement avec moins de projets sur la trajectoire, une vue plus claire de ceux qui partiront en production, et un sens beaucoup plus aigu de ce que leur organisation doit apprendre pour rendre la prochaine vague de travail plus facile.

Si votre équipe aborde un programme IA, ou tente d'en redresser un qui s'est essoufflé, le formulaire de brief ci-dessous est l'endroit où démarrer la conversation. Nous répondons sous un jour ouvré, avec le partner qui siégera sur le dossier plutôt qu'un responsable de relation.