Le sprint d'adoption de l'IA en 30/60/90 jours : une structure, pas un slogan

La plupart des petites et moyennes entreprises n’échouent pas dans l’adoption de l’IA parce qu’elles ont choisi le mauvais outil. Elles échouent parce que rien ne forçait une décision. Une version de cela : quelqu’un soulève l’IA en réunion de direction, un fournisseur réserve une démo, un abonnement est signé, et trois mois plus tard personne ne peut désigner ce qui a réellement changé. L’autre version : le sujet tourne comme point d’agenda permanent pendant deux trimestres et ne se convertit jamais en rien. Échec différent, même cause — aucune structure ne poussait l’organisation à bouger.

La solution n’est pas un meilleur outil. C’est d’emprunter un format qui fonctionne déjà pour la même raison dans un autre contexte : le plan à 30/60/90 jours utilisé depuis des décennies pour l’intégration des dirigeants, précisément parce que des jalons fixes forcent une décision au lieu de la laisser dériver. Appliqué à l’adoption de l’IA, il fait le même travail — trois jalons, trois livrables, trois moments honnêtes de go ou no-go, au lieu d’une initiative sans bords qui peut discrètement durer indéfiniment.

Chacune des trois phases répond à exactement une question, et répondre à plus d’une à la fois est la façon la plus sûre de gaspiller le premier trimestre. Les jours 1 à 30 répondent à où cela s’applique réellement et qui en est responsable — diagnostic, pas déploiement ; rien n’est encore acheté, et le livrable est un flux de travail nommé, un responsable désigné, et une définition de ce que « réussi » voudra dire au jour 90. Les jours 31 à 60 répondent à est-ce que ça marche, en heures que vous pouvez compter — un seul pilote protégé sur le flux de travail choisi en phase un, pas trois cas d’usage menés en parallèle parce que l’élan s’est accumulé entre-temps. Les jours 61 à 90 répondent à est-ce que vous l’étendez et comment vous l’empêchez de se dégrader discrètement ensuite — une décision explicite d’étendre, corriger ou arrêter, plus la gouvernance minimale dont une entreprise de trente à cent cinquante personnes a réellement besoin, pas un cadre conçu pour un grand groupe coté plusieurs tailles au-dessus.

Ce que cette série ne fera pas, c’est vous dire quelle plateforme acheter. C’est délibéré, pour deux raisons : la séquence fonctionne que vous aboutissiez à une pile open source auto-hébergée ou à une pile commerciale, et toute recommandation d’outil précise dans un texte comme celui-ci est généralement à moitié périmée au moment où on le lit. Elle n’est pas non plus écrite pour une entreprise dotée d’une fonction IA ou innovation dédiée — cela existe, mais ce n’est pas là que ça bloque. Elle est écrite pour l’entreprise où le PDG, le directeur des opérations ou deux opérationnels font le sprint en parallèle de tout ce qui est déjà sur leur bureau, ce qui signifie que chaque étape doit survivre à un temps limité et à l’absence de ligne budgétaire dédiée.

Les trois textes suivants parcourent chaque phase dans l’ordre — quoi auditer et décider dans les trente premiers jours, comment mener correctement un pilote dans les trente suivants, et comment prendre la décision d’étendre ou d’arrêter, avec juste assez de gouvernance, dans les trente derniers. Chacun se termine par une courte check-list : ce qui devrait être vrai à la fin de cette phase si le sprint fonctionne réellement, et pas seulement s’il tourne.

Le tableau de suivi d’une page

Toutes les check-lists des trois phases sur une seule page. Imprimez-la, ou copiez-la dans ce qui abrite le projet, et cochez chaque ligne à mesure qu’elle devient vraie.