Avant de continuer. Le gouvernement a présenté le Plan IA360 le 21 septembre 2026 : c'est une annonce, pas un appel à projets ouvert, et il n'y a aujourd'hui ni bases réglementaires ni délai de dépôt pour demander quoi que ce soit. Ce qui suit ne dépend pas de cette aide pour être vrai — c'est ce qui explique pourquoi tant de projets d'IA restent bloqués au stade du pilote, avec bono public ou sans lui.
Une entreprise teste un assistant qui répond aux e-mails, un classificateur de factures ou un chatbot pour le service client. Cela fonctionne bien en démo, avec les exemples que quelqu'un a préparés pour la présenter. Trois mois plus tard, plus personne ne l'utilise : l'équipe est revenue au processus manuel, ou le pilote reste « en test » sans que personne ne se rappelle pourquoi il n'est jamais passé en production. Ce n'est pas un problème du modèle. C'est presque toujours un problème dans la façon dont le projet a été posé avant d'écrire la première ligne de code.
C'est aussi, en partie, l'explication d'un chiffre que le Plan IA360 lui-même pose comme diagnostic de départ : seulement 21,1 % des entreprises espagnoles de dix salariés ou plus utilisaient l'intelligence artificielle au premier trimestre 2025, selon l'enquête TIC de l'INE, l'institut espagnol de la statistique (Plan IA360, projet moteur 10). L'objectif du plan est d'atteindre 55 % en 2030. Beaucoup de ces entreprises ont déjà testé l'IA à un moment ou un autre ; ce qui tire ce chiffre vers le bas, c'est qu'une bonne partie de ces pilotes n'est jamais devenue un usage réel et durable.
Le cas d'usage que personne n'a demandé
L'erreur la plus fréquente n'est pas technologique, elle est dans le point de départ. Quelqu'un à la direction décide « on va mettre de l'IA sur quelque chose » et choisit le processus qui sonne le mieux dans une présentation, pas celui qui fait vraiment gagner des heures à l'équipe. Un générateur de contenu spectaculaire rivalise mal, en heures de travail économisées, avec un classificateur ennuyeux qui trie cent e-mails par jour. Le pilote qui survit n'est pas le plus spectaculaire : c'est celui qui résout un goulot d'étranglement que quelqu'un peut montrer du doigt.
Il n'y a pas de ligne de base à mesurer
Si personne n'a noté, avant de commencer, combien de temps prenait le processus à la main et combien d'erreurs il comportait, il n'y a aucun moyen honnête de dire ensuite si le pilote a amélioré quelque chose. La comparaison devient subjective — « on dirait que cela va mieux » — et une impression subjective ne convainc pas celui qui doit décider si le projet continue ou s'arrête. La ligne de base se mesure avant le premier déploiement, elle ne se reconstruit pas de mémoire quand quelqu'un demande si cela a marché.
Le pilote n'a pas de propriétaire après la démo
Un pilote qui dépend de la personne qui l'a lancé meurt quand cette personne change de priorité. Il manque quelqu'un pour examiner les exceptions, pour décider si c'est le modèle qui s'est trompé ou si c'est le processus qui a changé, pour approuver le passage des dix cas de test aux cent qui arrivent chaque semaine. Sans responsable opérationnel, le pilote n'échoue pas bruyamment : il s'éteint tout seul, et trois mois plus tard personne ne saurait dire quand il a cessé d'être utilisé.
Les données n'étaient pas prêtes, et cela se découvre trop tard
Le document censé alimenter le système se révèle exister sous trois formats différents selon qui l'a rempli. L'historique des conversations avec les clients est réparti entre un CRM, une boîte mail et les notes d'une personne qui n'est plus dans l'entreprise. Rien de tout cela ne se voit en démo, car la démo se construit avec les données les plus propres qu'on a sous la main. Cela se voit en semaine trois de production réelle, quand arrive le premier cas qui ne correspond à aucun schéma prévu.
La méthode que le plan lui-même décrit pour le bono, sans avoir besoin de l'attendre
Le Plan IA360 fixe la façon dont il prévoit de mettre en œuvre le bono empresarial d'IA : « diagnóstico previo de madurez, identificación de un caso de uso concreto y medición posterior del impacto en productividad, con una primera fase que permita validar el modelo antes de su escalado » (« diagnostic préalable de maturité, identification d'un cas d'usage concret et mesure ultérieure de l'impact sur la productivité, avec une première phase permettant de valider le modèle avant sa mise à l'échelle ») (Plan IA360, projet moteur 11). Pas besoin d'un appel à projets pour copier cet ordre : on mesure d'abord d'où l'on part, ensuite on choisit un seul processus concret, et alors seulement on déploie, avec la façon de vérifier si cela a fonctionné déjà décidée à l'avance. C'est la séquence qui sépare un pilote qui atteint la production d'un pilote qui reste dans le dossier des projets en attente — le plan prévoit de l'exiger pour donner de l'argent public via le bono ; une entreprise peut l'appliquer sans attendre qu'existe un appel à projets.
Le responsable opérationnel n'est pas un détail administratif
Dans un déploiement d'agents bien conçu, la personne qui a autorité sur le processus signe l'action qui coûte de l'argent ou qui arrive directement au client, jusqu'à ce que le modèle démontre une stabilité au-dessus d'un seuil défini à l'avance — ce seuil est, littéralement, la ligne de base transformée en critère de décision. Quand le projet est plus simple — connecter le CRM, la messagerie et un tableur avec un modèle de langage au milieu, sans construire un agent complet —, la voie d'entrée la moins chère est généralement l'automatisation avec n8n : le flux et ses identifiants restent sur l'infrastructure de l'entreprise, même si le texte envoyé au modèle de langage sort ou non selon l'endroit où ce modèle s'exécute — la même question que traite où vivent vos données quand vous utilisez l'IA. Si cela fonctionne, c'est l'automatisation elle-même qui révèle s'il convient de monter en gamme vers quelque chose de plus sophistiqué.
Quatre signaux que votre pilote ne va pas passer à l'échelle
- Personne ne peut dire, avec un chiffre, ce qui s'est amélioré par rapport au processus précédent.
- Le projet a un porteur enthousiaste mais aucun responsable opérationnel désigné par écrit.
- Le cas d'usage a été choisi parce qu'il « faisait bien », pas parce que c'était le vrai goulot d'étranglement.
- Les données qui alimentent le pilote sont un échantillon trié, pas le flux réel et désordonné qui arrive chaque semaine.
Questions fréquentes
Que faire d'un pilote qui reste « en test » depuis des mois sans que personne ne le clôture ?
On lui fixe une date de révision et un responsable ayant l'autorité de décider, même en retard. Un pilote sans ces deux éléments ne meurt pas de façon visible : il reste ouvert indéfiniment, consommant de l'attention sans que personne ne le remarque jusqu'à ce que quelqu'un demande pourquoi il est encore là.
Qui doit être propriétaire du pilote au sein de l'entreprise ?
Quelqu'un ayant l'autorité opérationnelle sur le processus concerné, pas seulement celui qui a eu l'idée. Cette personne examine les exceptions, décide si un échec vient du modèle ou du processus et autorise le passage du volume de test au volume réel.
Un pilote qui ne passe pas à l'échelle signifie-t-il que l'IA ne convient pas à mon entreprise ?
Pas nécessairement. La plupart du temps, cela signifie que le cas d'usage, l'indicateur ou les données de départ n'étaient pas bien définis avant de commencer, pas que la technologie a échoué. Répéter la même erreur avec un autre processus donne le même résultat.
Ai-je besoin d'un projet complexe pour commencer, ou puis-je tester avec quelque chose de petit ?
La seconde option fonctionne généralement mieux. Un flux restreint avec de l'automatisation et un modèle de langage comme simple nœud supplémentaire est, pour beaucoup de PME, la façon la moins chère de vérifier si le processus passe à l'échelle avant de construire quelque chose de plus ambitieux.
Pour aller plus loin
Cette méthode de validation avant mise à l'échelle est la même que prévoit le guide complet du Plan IA360 pour le bono empresarial. C'est aussi la logique qui sous-tend la Red NEURONA (« réseau NEURONA »), pensée pour qu'une PME teste avec ses propres données avant de s'engager.