Un COO pilote l'opération : flux, capacité, qualité, continuité. Des pilotes IA qui donnent de bons résultats dans un coin isolé de l'entreprise n'en disent que peu à ce sujet. La question qui compte n'est pas de savoir si quelque chose fonctionne dans un dispositif de test, mais si cela continue à fonctionner une fois que cela devient partie intégrante de l'opération quotidienne, avec toutes les dépendances qui en découlent.
Une opération qui a été organisée d'une certaine manière est coûteuse à faire évoluer en arrière. Si une application d'IA est déployée avant que les processus, les données et les responsabilités ne soient en ordre, cela ne crée pas d'accélération mais du travail supplémentaire : corrections, exceptions, personnes qui doivent tout de même vérifier ce qu'un système aurait déjà dû faire. Ce risque touche directement le COO, car l'opération est ce dont il doit répondre. Un pilote qui semblait convaincant en démonstration, et qui six mois plus tard entraîne une livraison perturbée ou un traitement d'erreurs supplémentaire, est un problème qui finit sur son bureau.
Le risque inverse existe également : attendre trop longtemps avant de passer à l'échelle parce que personne ne peut indiquer si l'organisation est prête. Les concurrents ou d'autres entités de l'entreprise continuent alors à prendre de l'avance, sans qu'il y ait de raison fondée à cela. Les deux risques naissent de la même lacune : il n'existe pas de vision partagée de la situation réelle de l'organisation.
Un COO veut une base sur laquelle construire des décisions, qui ne dépende pas de l'enthousiasme d'une seule équipe pilote. Il veut savoir si l'organisation, indépendamment de projets individuels, est structurée pour porter l'IA : les processus sont-ils décrits et reproductibles, l'infrastructure est-elle suffisamment stable, les données sont-elles disponibles et fiables là où elles sont nécessaires. C'est un autre type de question que « cette application spécifique fonctionne-t-elle ». C'est la question de savoir si le socle est solide, indépendamment de l'application qui sera construite dessus par la suite.
Ce socle se compose de plusieurs couches, et l'ordre dans lequel elles sont interrogées n'est pas arbitraire. L'organisation, l'infrastructure informatique et la gestion des données déterminent ce qui est possible ; les dimensions qui en dépendent, comme la prise de décision ou la collaboration autour de l'IA, ne peuvent pas aller plus loin que ce que cette base permet. Un COO qui sait cela pose ses questions dans le bon ordre plutôt que de commencer par l'application la plus visible.
Un COO n'accepte pas une réponse qui repose sur une seule opinion. « L'équipe est prête » est une affirmation d'une seule personne, fondée sur ce que cette personne voit depuis sa position. Un responsable informatique, un manager opérationnel et un chef d'équipe voient souvent une organisation différente, même lorsqu'ils parlent du même service. Cette dispersion est précisément la raison pour laquelle un score émanant d'une seule personne ne suffit pas : elle masque des désaccords qui, plus tard, lors de la mise à l'échelle, refont surface.
C'est pourquoi une mesure qui fait évaluer plusieurs personnes séparément fonctionne, à travers cinq niveaux — de baseline à foundation, activation, insight et enfin intelligence — répartis sur sept dimensions. Pas pour calculer une moyenne, mais pour voir où les réponses divergent. Une forte dispersion sur une dimension constitue déjà en soi une information : cela signifie qu'il n'existe pas de vision partagée, ce qui est différent d'un niveau bas. Une organisation qui obtient un score bas mais unanime sur toutes les dimensions sait au moins où elle se situe. Une organisation avec une forte dispersion ne le sait pas encore, et doit d'abord clarifier cela avant qu'un niveau ne signifie quoi que ce soit.
Un COO n'accepte pas non plus une réponse qui suggère une garantie. Une mesure de maturité dit quelque chose sur l'état de l'organisation à ce moment précis, pas sur ce qu'une application d'IA produira plus tard. Cette distinction n'est pas subtile pour quelqu'un ayant une responsabilité opérationnelle : il sait que la maturité est une condition, pas un résultat.
L'opération n'est pas la seule couche où ce type de questions se pose. Ce qui, pour le COO, représente la continuité des processus, constitue pour d'autres rôles dans l'entreprise un autre arbitrage : ce à quoi un CIO prête attention en matière de maturité IA décrit la question du point de vue de l'infrastructure et de l'architecture des systèmes, tandis que ce à quoi un CHRO prête attention en matière de maturité IA aborde ce que cela exige des personnes et des rôles. Pour les entreprises dont l'opération est structurée à partir de projets et de sites plutôt que d'un processus central, d'autres schémas s'appliquent, comme on peut le lire dans où en est le secteur de la construction en matière de maturité IA.
La mesure qui rend cette dispersion visible est en cours de développement. Ceux qui s'inscrivent sur la liste d'attente y auront accès dès que l'outil sera prêt à l'emploi. Il n'y a actuellement aucun rapport à télécharger ni de session à réserver ; il y a un instrument en développement, construit sur la question qu'un COO pose effectivement, et non sur la question qui est facile à répondre.
La mesure de maturité répond à la question de savoir si l'organisation peut porter l'IA : si les fondations sont en place pour construire quelque chose de durable. Une fois cette vision établie, la question passe de la capacité de portage au contenu : quelle partie du travail peut effectivement être reprise par l'IA, tâche par tâche, plutôt qu'à l'échelle de toute l'organisation. C'est une autre mesure, avec un autre type de réponse, et un COO la trouve dans le scan de travail de FTE TO AI.
Vraag maar wat er moet staan voordat AI in uw organisatie kan landen.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.