Les 90 premiers jours d'adoption de l'IA dans une PME : une feuille de route

Une PME qui a décidé d'adopter l'IA se retrouve presque toujours devant la même question mal posée : « quel outil vais-je acheter ? ». C'est la mauvaise question, ou plutôt : c'est la troisième, pas la première. Avant un outil, il faut un parcours — et le parcours, quand il fonctionne, a une forme reconnaissable et une durée précise. Les playbooks d'adoption les plus solides en circulation — celui, public, de GitHub est le plus lisible — le rythment tous de la même façon : les 30 premiers jours pour les fondations, les 90 premiers jours pour l'élan, puis le régime continu pour l'échelle. Cet article reprend cette structure et la calibre sur une petite entreprise italienne : quoi faire, dans quel ordre, et avec quels contrôles, durant les trois premiers mois.

Il vaut la peine de partir d'une donnée inconfortable, car elle explique pourquoi la feuille de route compte plus que l'outil. Les analyses sectorielles s'accordent sur deux chiffres : la grande majorité des agents IA n'arrive jamais en production, et environ 29 % des projets sont abandonnés dans les 90 jours. Non pas pour des limites techniques — les outils fonctionnent — mais parce qu'ils sont partis sans savoir où ils allaient, sans responsable et sans contrôles. Les 90 jours ne sont pas un compte à rebours arbitraire : ils sont exactement la fenêtre dans laquelle une adoption mal engagée meurt. Bien l'engager, c'est tout l'enjeu.

Semaines 1–2 : savoir où vous en êtes, avant d'acheter quoi que ce soit

La première erreur est d'acheter un outil avant d'avoir mesuré le point de départ. La première chose qu'un parcours sérieux produit n'est pas un logiciel, mais une photographie honnête de la situation de l'entreprise. Les modèles de maturité que le marché utilise pour l'établir — de Gartner à Deloitte — renvoient une réponse en une ligne : « vous êtes au stade X sur 5 ». Mais la version utile pour une PME ne donne pas un seul chiffre : elle sépare le score en deux domaines — les Fondations (données, technologie, compétences) et la Stratégie (gouvernance, risque, objectifs, culture) — de façon à expliquer pourquoi vous êtes bloqué, pas seulement à quel point. C'est une distinction qui change les décisions à prendre : de bonnes fondations mais aucune stratégie, c'est un problème inverse de celui qui a les idées claires mais les données en désordre.

Il y a ici un point qui vaut particulièrement pour l'Italie. Les indices de readiness les plus connus (Cisco, pour ne citer que lui) pèsent beaucoup l'infrastructure et les données — reflet d'un monde de grandes entreprises. Pour la plupart des PME italiennes, le goulot d'étranglement n'est pas l'infrastructure : c'est la stratégie et le processus. Elles savent qu'elles doivent faire quelque chose avec l'IA, mais ne savent ni quoi ni par où. Une évaluation calibrée sur la PME déplace donc le poids sur la stratégie, la gouvernance et la culture, et indique de là quel service est vraiment prêt à démarrer en premier. C'est le travail que nous avons rendu self-serve et gratuit : notre évaluation d'AI-readiness donne en deux minutes cette photographie — à quel stade vous en êtes par domaine et quel service il convient d'ouvrir en premier. C'est le kilomètre zéro de la feuille de route ; sans elle, chaque pas suivant est un pari.

Semaines 3–6 : un seul cas d'usage, avec un responsable

La photographie en main, la tentation est de partir sur trois fronts à la fois. C'est l'erreur qui produit ces 29 % d'abandons. La règle des 90 premiers jours est l'inverse : un seul cas d'usage, dans le service que l'évaluation a désigné comme le plus prêt, mené jusqu'en production. Pas un essai garé dans un coin — un flux que quelqu'un utilise vraiment chaque jour, avec un avant et un après mesurables. Gagner une fois, en petit et pour de vrai, vaut mieux que cinq pilotes abandonnés.

Le second ingrédient est celui qui fait la différence entre un projet qui dure et un qui s'évapore dès que l'enthousiasme retombe : un responsable. Les playbooks enterprise l'appellent Center of Excellence et lui attribuent cinq fonctions distinctes — qui décide des priorités, qui a le dernier mot, qui forme les personnes, qui tient les standards et les modèles réutilisables, qui surveille les signaux de valeur. Une PME n'a pas cinq équipes pour ces tâches, et elle n'en a pas besoin : il lui faut une ou deux personnes qui couvrent l'ensemble de ces cinq fonctions. Non pas le rang hiérarchique, mais la titularité : quelqu'un dont le nom figure à côté du cas d'usage. Sans un responsable qui a un nom, le flux n'est à personne, et ce qui n'est à personne est abandonné en premier.

Ce premier cas d'usage n'est pas un épisode isolé : c'est la première entrée d'un playbook qui grandit. Chaque entrée porte avec elle une phase — pilote, puis passage à l'échelle, puis régime — de sorte qu'à mi-parcours on puisse filtrer par « ce qui vient ensuite » plutôt que de relire des pilotes déjà clos. Comment une entrée de playbook est faite à l'intérieur — la structure, le responsable, les contrôles rattachés — nous l'avons décomposée dans l'anatomie d'un AI Workflow Design.

Dès le jour 1, pas au jour 90 : les contrôles minimaux

L'erreur la plus coûteuse des 90 premiers jours est de repousser la gouvernance à la fin — « faisons d'abord fonctionner la chose, puis mettons les contrôles ». C'est exactement l'inverse : les contrôles minimaux doivent être mis en place le jour où le cas d'usage démarre, car les ajouter ensuite revient à redessiner le flux, pas à le retoucher. Nul besoin d'un appareil lourd — il faut quatre gestes, tous vérifiables avant de passer en production :

• Classez le risque. Dans quel niveau de l'AI Act le cas d'usage tombe-t-il ? La plupart des usages en PME — un copilote interne, la génération de contenus, un bot de premier niveau — relèvent du niveau minimal ou limité, où la charge est légère. La machinerie lourde ne se déclenche que pour les usages à haut risque (recrutement, crédit, données biométriques) : si votre premier cas d'usage en fait partie, vous savez déjà qu'il faut plus de prudence.
• Vérifiez si une AIPD est nécessaire. Si le flux prend des décisions automatiques ayant des effets sur les personnes, ou traite des données sensibles à grande échelle, l'analyse d'impact RGPD est due — et une AIPD « standard » ne suffit pas, car elle passe à côté des risques propres à l'IA (opacité du modèle, dérive, mémorisation, droit à l'oubli). C'est une question à se poser dès le jour 1, pas à découvrir lors d'un contrôle.
• Mettez un humain dans la boucle. Aucun résultat touchant un client, un candidat ou l'argent ne devrait partir sans un passage humain. C'est le contrôle qui vaut plus que toute la politique écrite, et il doit être conçu dans le flux, pas accroché à côté.
• Gardez une trace. Qui a fait quoi, quand, avec quelle entrée. Pour les cas à haut risque, l'AI Act demande de conserver les logs pendant au moins six mois ; pour tous les autres, la traçabilité est de toute façon ce qui vous permet de répondre à un auditeur, de reconstituer une erreur et de défendre une décision.

Ce sont les mêmes quatre gestes que notre overlay de conformité rattache à chaque workflow que nous concevons — non pas comme une formalité en aval, mais comme partie intégrante de la conception. Le raisonnement complet, avec la taxonomie du risque et le pourquoi de chaque contrôle, se trouve dans l'article sur les contrôles qui rendent un cas d'usage défendable.

Le cap des 90 jours : du pilote à la méthode

Si les six premières semaines se sont bien passées, au jour 90 vous n'avez pas « un outil de plus » : vous avez un cas d'usage en production, un responsable qui a un nom, les contrôles rattachés et — ce qui compte le plus — une méthode que l'on peut répéter sur le deuxième service sans repartir de zéro. Il vaut la peine de fixer trois points de contrôle en chemin :

• Jour 30 — fondations. La photographie de readiness est faite, le service de départ est choisi, le responsable est nommé, les contrôles minimaux sont définis. Aucun outil forcément acheté encore : d'abord le pourquoi et le qui, puis le quoi.
• Jour 60 — élan. Le premier cas d'usage est vivant et quelqu'un l'utilise chaque jour. On recueille les premiers chiffres honnêtes et la première « histoire de réussite » interne — celle qui convainc le deuxième service de s'y essayer.
• Jour 90 — échelle. Le cas d'usage tient tout seul, le deuxième est en file avec la même structure, et le playbook compte désormais deux entrées au lieu d'une. À partir de là, l'adoption n'est plus un projet : c'est une façon de travailler.

Une dernière chose sur les chiffres, car c'est le point où les adoptions se bercent d'illusions. Mesurer le succès par « combien de personnes l'utilisent » est la première marche, pas la dernière : après l'ampleur d'usage vient la profondeur (qui l'utilise vraiment, et pour quoi) et seulement à la fin l'impact sur le business — le temps gagné, les erreurs évitées, les revenus touchés. Un pilote que tout le monde a « essayé » mais que personne n'utilise en profondeur n'est pas un succès : c'est un abandon qui ne s'est pas encore déclaré. Les 90 jours servent à mener au moins un cas d'usage jusqu'à la troisième marche.

La différence entre celui qui, au jour 90, a une méthode et celui qui a un outil de plus inutilisé ne tient pas à la technologie — elle tient au fait d'avoir fait les choses dans le bon ordre : d'abord savoir où vous en êtes, puis un seul cas d'usage avec un responsable, les contrôles dès le jour 1, et l'échelle seulement après. C'est exactement l'ordre dans lequel nous greffons l'IA dans une entreprise.

Le premier pas, cependant, est toujours le même et vous pouvez le faire maintenant : savoir où vous en êtes. L'évaluation gratuite vous donne en deux minutes la photographie de départ et le service par lequel il convient d'ouvrir vos 90 jours. Si vous voulez ensuite comprendre comment passer du comprendre au faire, parlons-en — sans engagement.

Cet article a une visée d'orientation. Les pourcentages d'abandon et les délais cités proviennent d'analyses de marché et de sources sectorielles, non vérifiées de manière indépendante, et doivent être lus comme des indications de direction, non comme des garanties. Les niveaux de risque, les obligations d'AIPD et les durées de conservation des logs dépendent du cas d'usage et de la réglementation en vigueur — l'EU AI Act est en évolution — et doivent toujours être vérifiés au regard du contexte de chaque entreprise avant d'agir.