Deux déploiements IA qui peuvent s’enliser, et comment assurer la suite

Imaginons six pilotes : quatre fonctionnaient techniquement, mais aucun n’a aujourd’hui de responsable d’exploitation. Cet exemple montre l’écart entre prouver un concept et maintenir un service.

Ce qui arrive ensuite porte un nom. Un cimetière de PoC. Des preuves de concept qui ont prouvé le concept et ont quand même cessé de compter. Du budget éparpillé entre des sièges Copilot que personne n'ouvre, quelques fonctions IA boulonnées sur des outils SaaS, une ou deux solutions ponctuelles qui ont résolu exactement un point. Et un conseil qui repose la même question à la fin de chaque trimestre. Où est le retour sur investissement.

Un pilote porté par la direction et un déploiement large de licences peuvent fonctionner. Chacun échoue quand le travail d’exploitation après le lancement n’a pas de responsable.

La première façon est le mandat. La direction choisit un cas d'usage, sélectionne une équipe, lui donne du budget et une couverture politique, et le pilote se passe magnifiquement. Évidemment. Il a un sponsor, une échéance, et les personnes les plus affûtées du bâtiment. Puis quelqu'un prononce le mot échelle, et tout se replie sous son propre poids. L'équipe qui l'a fait marcher était le goulot d'étranglement. Il n'y en avait qu'une, et elle a déjà un métier.

La deuxième façon est le réflexe inverse. Acheter des licences pour tout le monde, envoyer un email général avec un lien, démocratiser la chose. L'ennui, c'est qu'un identifiant n'est pas une compétence. La plupart des gens cliquent une fois, posent une question paresseuse, reçoivent une réponse médiocre, décident que l'outil est surcoté, et retournent à leur boîte mail. Vous avez payé mille sièges et obtenu quarante utilisateurs. Dont trente allaient s'y mettre de toute façon.

Une approche meurt de faim parce qu'il n'y a jamais eu qu'une équipe derrière. L'autre se noie parce qu'un lien dans un email n'est pas une raison de s'y intéresser. Même cimetière, deux routes pour y entrer.

L'IA ne ressemble pas aux trois dernières choses que votre DSI a déployées. Le cloud, l'entrepôt de données, la migration CRM dont personne ne garde un bon souvenir. Celles-là, vous les installiez en espérant que les gens les tolèrent. L'IA, quand elle atterrit sur le vrai problème de la bonne personne, fait quelque chose qu'elles n'ont jamais fait. Elle crée un évangéliste. Quelqu'un l'essaie sur une tâche qu'il déteste sincèrement, sent le temps qu'elle lui rend, et ne peut plus s'empêcher d'en parler au déjeuner. Appelez-les power users. Ils portent deux choses qu'aucun fournisseur et aucun consultant extérieur ne peut livrer dans une boîte. Ils connaissent vos données, vos processus, vos exceptions étranges, la raison pour laquelle l'étape quatre existe. Et ils voulaient ça avant qu'on le leur dise.

Un premier processus utile donne aux collègues quelque chose de concret à évaluer. La réutilisation peut progresser si l’équipe formalise la méthode, explique ses limites et réserve du temps pour apprendre. La vitesse d’adoption doit être mesurée.

Le motif en dessous est presque ennuyeux, et c'est pour ça que la plupart des entreprises le sautent. Une session large, co-sponsorisée par la direction, pour que les gens sachent que c'est permis et que ça vaut une heure de leur semaine. Ça crée de la traction au lieu de la pression. Puis des ateliers pratiques, en petit groupe, avec ceux qui se sont penchés en avant, sur leurs vrais problèmes et pas sur une démo propre en bac à sable. Et ensuite les champions émergent tout seuls. Vous ne les nommez pas. Vous ne pourriez pas même en essayant, parce que la seule chose qu'on ne met pas dans un plan de staffing, c'est la motivation.

Pendant ce temps, l'équipe plateforme interne cesse d'être le portail et devient le plancher. Elle pose les garde-fous et les fondations partagées. Les power users construisent dessus pour leur coin de l'activité. Un gardien ralentit tout à la vitesse d'une seule file d'attente. Un plancher permet à cent personnes de bouger en même temps, à l'intérieur de lignes tracées exprès.

Alors où se place quelqu'un de l'extérieur, si tout le moteur tourne sur des gens qui étaient déjà dedans.

Clarifier responsabilité de livraison et maîtrise du client

Le premier type emménage. Ils envoient des ingénieurs, vous construisent quelque chose de sur-mesure et sincèrement impressionnant, et restent. Le travail tourne sur eux, et il tourne bien, jusqu'à ce que le contrat se termine ou que le sol bouge sous les pieds de tout le monde, ce qui dans ce domaine arrive à peu près chaque trimestre. Alors la chose qu'ils ont construite devient une maison que personne parmi ses habitants ne sait recâbler. Vous n'avez pas acheté une capacité. Vous en avez loué une, et le bail est toujours en attente de renouvellement.

Nous travaillons directement avec l’équipe client et les personnes qui connaissent les exceptions. L’accès aux cas réels et aux décideurs compte ; le modèle de livraison ne repose pas sur une promesse de présence permanente ou sur site.

Solve IT construit le premier processus avec ses futurs utilisateurs et reste responsable jusqu’à la production, l’adoption et au transfert. La réception comprend une équipe capable de l’exploiter et de traiter les exceptions. Un support géré facultatif a son propre périmètre convenu ; le client conserve les accès.

Le contrat précise les deux côtés : ce que le partenaire doit prouver et ce que le client doit fournir. Un support continu peut être utile sans rendre l’entreprise dépendante d’un seul fournisseur.

Vous savez déjà quel dossier dort sur votre drive. Le pilote calé, les mille sièges et quarante utilisateurs, le deck présenté une fois. Pourquoi la dernière vague est morte, vous pouvez déjà l'expliquer en une phrase. La question plus difficile est plus petite que ça : quel vrai problème, possédé par quelle vraie personne, mérite qu'on construise la première machine autour. C'est une conversation qui vaut la peine avant de renouveler quoi que ce soit.