Un pilote est lancé. Une équipe, un outil, une période de quelques semaines ou mois. À la fin, vient un retour : c'était une bonne impression, les gens étaient enthousiastes, certaines choses ont été plus rapides. Et une décision est alors prise sur la base de ce ressenti, alors que personne n'avait fixé au préalable à quelle question le pilote devait réellement répondre.
C'est là le piège. Pas le pilote en lui-même, mais l'absence d'une question à laquelle le pilote devait répondre. Sans cette question, tout résultat est un bon résultat, et c'est précisément le problème. Un pilote sans accord sur ce qui doit être démontré ne peut pas échouer, et ne peut donc rien prouver non plus.
Un pilote donne l'impression d'être une manière sûre de commencer. Démarrer petit, voir ce qui se passe, puis étendre si cela fonctionne. Cela semble raisonnable, et dans une situation stable, ça l'est effectivement. Mais l'IA ne touche pas seulement l'équipe qui mène le pilote. Elle touche la manière dont les données sont enregistrées, qui décide de quoi, et quels systèmes doivent communiquer entre eux. Un pilote qui ne mesure rien à ce sujet ne mesure donc rien non plus quant à la question de savoir si le reste de l'organisation obtiendrait le même résultat.
La logique du « d'abord essayer en petit » suppose que le succès à petite échelle se traduit par un succès à grande échelle. C'est précisément pourquoi étendre sans que la base soit en place ne donne rien : ce qui fonctionnait dans un pilote le devait souvent à des circonstances absentes ailleurs. Une équipe motivée, un jeu de données propre, un responsable qui, par hasard, s'est impliqué. Sans accord sur ce qui devait être testé, il reste impossible de savoir si le résultat provenait de la technologie ou des circonstances exceptionnelles dans lesquelles elle a été testée.
Il y a quelques signaux caractéristiques.
Le premier signal est que le pilote se termine par un récit plutôt que par une réponse. On raconte ce qui s'est passé, mais personne ne peut dire si la question posée au préalable — qui en réalité n'a jamais existé — a été résolue.
Le deuxième signal est que le pilote était isolé du reste de l'organisation. Une équipe, un cas d'usage, aucun lien avec les systèmes ou services qui devraient porter le résultat si cela fonctionne. C'est le même piège que lorsque un pilote ne fonctionne que dans son propre coin : un succès isolé en dit peu sur ce qui se passe lorsque le reste de l'organisation doit s'y raccorder.
Le troisième signal est que personne ne s'approprie le pilote. Il y a un chef de projet, peut-être un fournisseur, mais aucun propriétaire responsable de ce qui doit se passer après le pilote. On ne s'en rend compte qu'une fois le pilote terminé, lorsque la question « et maintenant » reste sans réponse, exactement le schéma qui apparaît lorsque une démonstration sans propriétaire ne donne rien.
Le quatrième signal est que la technologie a été testée, mais pas la structure dans laquelle elle doit fonctionner. Rôles, responsabilités, lignes de décision : ils sont restés inchangés pendant le pilote, et c'est précisément pourquoi la technologie superposée à une structure inchangée ne donne rien. Un pilote qui ne touche pas à la structure teste uniquement si la technologie fonctionne dans un environnement qui n'a pas besoin de changer. C'est une question différente de celle de savoir si l'organisation est prête à travailler avec elle.
L'ordre dans lequel la maturité en matière d'IA se construit n'est pas arbitraire. L'organisation, l'infrastructure informatique et la gestion des données constituent la base sur laquelle les dimensions dépendantes — comme la manière dont les personnes collaborent avec l'IA ou dont les décisions sont prises — peuvent seulement s'appuyer. Un pilote qui ignore cet ordre mesure en réalité autre chose que ce qu'il prétend mesurer. Il mesure la créativité d'une équipe à un moment donné, pas la maturité de l'organisation dans son ensemble.
C'est aussi là où un CEO et un COO portent généralement un regard différent. Ce qu'un CEO examine en matière de maturité IA diffère de ce qu'un COO évalue à ce sujet, et un pilote sans point de mesure fixé au préalable laisse les deux sans repère. La question n'est pas de savoir si le pilote était agréable, mais s'il dit quelque chose sur les dimensions qui doivent porter le reste.
La mesure de maturité de hybridresourcing.com vise à rendre cet accord préalable possible. Cinq niveaux, du baseline à l'intelligence, sur sept dimensions, avec une session de scoring où plusieurs personnes évaluent indépendamment les unes des autres afin que la dispersion apparaisse clairement, plutôt qu'une seule impression prise pour une vérité. Cela permet de visualiser où se situe réellement l'organisation, avant de lancer un nouveau pilote qui devrait prouver après coup ce qui n'a jamais été fixé au préalable.
Cette mesure porte sur la question de savoir si l'organisation peut porter l'IA : si la base est en place pour faire fonctionner quelque chose de manière structurelle. Une fois cette question résolue, une autre question devient possible, à savoir quelle part du travail réel l'IA peut reprendre. Cette question est résolue par le scan de travail de FTE TO AI, qui calcule, tâche par tâche, quelle part peut être transférée à l'IA. L'outil de cette mesure de maturité est en cours de développement ; celles et ceux qui souhaitent l'utiliser dès sa disponibilité peuvent s'inscrire sur la liste d'attente.
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.