Quel projet d'IA financera le Plan IA360, et comment le monter
Le bono du Plan IA360 dessine cinq briques d'un projet d'IA : diagnostic, cas d'usage, formation, intégration au processus et mesure. Comment les monter.
État au 22 septembre 2026. Le Plan IA360 a été présenté le 21 septembre 2026. Il n'existe aucun appel à projets publié, aucune base réglementaire, aucun délai de candidature. L'appel général du bono, doté de 600 millions d'euros, n'est attendu qu'« antes de final de 2027 » (d'ici la fin de 2027), après un pilote contrôlé prévu au « primer semestre de 2027 » (premier semestre 2027). Rien de ce qui suit n'est une démarche : c'est la description d'un projet, avec ou sans bono.
Le gouvernement a présenté le Plan IA360 le 21 septembre 2026, organisé en huit axes d'action et quatorze projets phares ; la communication officielle le résume aussi en quatre grands objectifs (muscle technologique, adoption économique, gouvernance et contrat social), qui correspondent à un niveau de lecture différent, non contradictoire avec les huit axes du document technique. Vous pouvez consulter le détail complet dans le document officiel du plan ; nous n'allons pas les résumer un par un ici, car ce n'est pas ce qui intéresse une entreprise qui ne gère ni infrastructure de calcul ni politique de talents.
L'intérêt se cache dans le projet phare numéro 11, le bono empresarial de inteligencia artificial (chèque d'aide à l'intelligence artificielle pour les entreprises). Le plan ne se contente pas d'annoncer une enveloppe de 600 millions d'euros : il décrit, avec bien plus de détail qu'à l'accoutumée pour un document de ce type, ce que doit être le projet qui reçoit cet argent. Il dit, littéralement, que « la implantación incorporará 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 » (la mise en œuvre intégrera un diagnostic préalable de maturité, l'identification d'un cas d'usage concret et une mesure ultérieure de l'impact sur la productivité, avec une première phase permettant de valider le modèle avant son passage à l'échelle). Il ajoute que la conception du bono « incluiría pagos por hitos y condiciones acerca de formación en IA de los trabajadores e incorporación de la IA a los procesos internos de los beneficiarios » (inclurait des paiements liés à des jalons et des conditions portant sur la formation à l'IA des salariés et l'intégration de l'IA aux processus internes des bénéficiaires).
Lisez-le sans le filtre administratif et il dit autre chose : diagnostic, cas d'usage, pilote, formation, intégration au quotidien, mesure du résultat. Ce n'est pas une nouvelle exigence bureaucratique : c'est, presque mot pour mot, la façon de monter un projet d'IA qui ne finit pas abandonné au bout de trois mois. Le plan n'est que le prétexte de cet article ; le sujet, c'est votre projet, qu'il y ait un bono derrière ou qu'il n'y en ait jamais.
Étape 1 — Savoir quoi automatiser avant d'automatiser quoi que ce soit
L'erreur la plus coûteuse dans un projet d'IA n'est pas de mal choisir le modèle. C'est de commencer à construire avant de savoir quel problème on résout. Une entreprise qui saisit à la main chaque facture fournisseur parce que personne n'a pris le temps de regarder combien en arrivent par mois, ou une équipe qui répond au même type de demande au support technique quinze fois par semaine sans que personne ne l'ait jamais compté, n'a pas besoin d'un modèle en premier lieu : elle a besoin d'un diagnostic.
Un diagnostic de maturité regarde trois choses : quelles données possède l'entreprise et dans quel état elles se trouvent, quels processus pourraient vraiment en tirer profit, et qui va les maintenir une fois que le projet aura cessé d'être une nouveauté. Et parfois, plus souvent qu'un client ne s'y attend, la conclusion honnête est que ce problème précis, ce n'est pas l'IA qui le résout, mais la réorganisation d'un processus ou la formation d'une personne. Vendre un projet d'IA là où ce n'est pas nécessaire est le moyen le plus rapide de vider ce mot de tout son sens dans une entreprise. C'est le travail d'un diagnostic de maturité et feuille de route.
Étape 2 — Le cas d'usage concret : ce qui change, et pour qui
Le plan est explicite sur le type de projet qui a de la valeur : des services qui utilisent les modèles fondationnels « como insumo » (comme matière première), en y intégrant « valor añadido propio mediante desarrollo, integración, conocimiento sectorial, tratamiento de datos o rediseño de procesos » (leur propre valeur ajoutée, par le développement, l'intégration, la connaissance sectorielle, le traitement des données ou la refonte des processus). Et il est tout aussi explicite sur ce qui n'est pas éligible : « el bono no financiará la mera suscripción a licencias » (le bono ne financera pas le simple abonnement à des licences).
Cette frontière, traduite en processus réels, sépare deux choses très différentes. Activer un assistant générique et espérer que l'équipe change ses habitudes toute seule, c'est une licence. Construire un agent qui lit la facture du fournisseur, la vérifie par rapport à la commande et ne demande une confirmation humaine que lorsque quelque chose ne correspond pas, c'est une refonte de processus avec une valeur ajoutée propre. La différence ne tient pas au modèle qui se trouve derrière : elle tient au fait que quelqu'un ait pris le temps de repenser le processus autour de lui. Nous entrons dans le détail, avec davantage d'exemples du type de projet qui correspond ou non au critère littéral du plan, dans quels projets d'IA correspondent au bono IA360.
Lorsque le processus dépend de la recherche d'informations dispersées entre contrats, manuels ou anciens e-mails, le cas d'usage est souvent différent : un système de recherche documentaire qui cite la source exacte de chaque réponse, plutôt que d'obliger quelqu'un à relire un PDF de soixante pages à chaque doute.
Étape 3 — Former celui qui va l'utiliser, pas seulement celui qui l'a acheté
Le plan prévoit, au conditionnel, « formación en IA de los trabajadores » (une formation à l'IA des salariés), et cela a du sens : un projet d'IA que seule la personne qui l'a commandé comprend meurt dès que cette personne change de poste. La formation qui fonctionne n'est pas un exposé générique d'une après-midi sur ce qu'est un modèle de langage, mais quelque chose de différent selon qui la reçoit : la direction a besoin de comprendre les risques et la gouvernance pour décider ; l'équipe technique a besoin de comprendre l'architecture et l'exploitation pour le maintenir ; l'équipe qui utilise l'outil au quotidien a besoin de comprendre ce qu'elle peut lui demander et où se trouve la limite, pour ne pas se fier à une réponse qu'il faudrait vérifier. C'est l'approche d'une formation en entreprise par rôles, sur les propres cas de l'entreprise, finançable via FUNDAE (l'organisme public espagnol de financement de la formation professionnelle).
Étape 4 — Que ça reste dans le processus, pas à côté
C'est là que meurent plus de projets d'IA que personne ne le reconnaît publiquement : le pilote fonctionne, tout le monde applaudit à la démo, et trois mois plus tard, plus personne ne l'utilise parce qu'il continue de vivre en dehors du flux de travail réel. Le plan appelle cela « incorporación de la IA a los procesos internos de los beneficiarios » (l'intégration de l'IA aux processus internes des bénéficiaires), et c'est la partie la plus négligée, parce que ce n'est pas la partie spectaculaire.
L'intégrer réellement signifie que le système entre par où le travail entre déjà aujourd'hui (le courriel, le CRM, l'ERP, le scanner de l'entrepôt) et sort par où il est déjà relu. Une automatisation qui connecte les outils que l'entreprise utilise déjà, avec le modèle comme une étape de plus dans le flux et non comme un onglet à part qu'il faut penser à ouvrir, est souvent l'étape qui décide si le projet survit au premier trimestre.
Un exemple courant : un système de recherche documentaire qui répond avec précision, mais auquel seul le responsable du projet accède, parce qu'il faut ouvrir un chat à part pour l'interroger. Ce même système connecté au courriel ou au CRM, de sorte que la réponse arrive là où l'on travaille déjà, est celui qui change vraiment le processus. La technologie ne varie pas ; ce qui change, c'est si quelqu'un s'est chargé de l'intégrer au flux quotidien plutôt que de la laisser comme une expérience parallèle.
Étape 5 — Mesurer l'impact, pas seulement le lancement
Le dernier élément qu'énumère le plan est « medición posterior del impacto en productividad » (une mesure ultérieure de l'impact sur la productivité). Cela paraît évident jusqu'à ce qu'on essaie de le faire : mesurer l'impact exige d'avoir noté, avant de commencer, combien de temps prenait le processus, combien il coûtait et combien d'erreurs il comportait. Sans cette ligne de base, tout chiffre présenté ensuite n'est qu'une opinion avec des décimales.
Il n'est pas nécessaire d'avoir un service data pour établir cette ligne de base. Il suffit de noter les heures que consomme aujourd'hui le processus, son coût horaire et une estimation honnête de la part qui est automatisable. Pour estimer à l'avance si cela en vaut la peine, la calculatrice de ROI de l'automatisation sert à ça ; la mesure arrive ensuite, en comparant la ligne de base avec le processus déjà transformé.
Qui fait quoi à chaque étape, en bref
Il n'est pas nécessaire d'avoir un service IA en interne pour parcourir les cinq étapes ; il faut savoir à qui revient chacune. Voici, en un coup d'œil :
| Étape du projet | En pratique | Service associé |
|---|---|---|
| Diagnostic de maturité | Quelles données existent, quels processus prioriser, feuille de route | Advisory |
| Cas d'usage : exécution | Un agent qui exécute un processus avec validation humaine | Agents |
| Cas d'usage : connaissance | Recherche sur la documentation interne, avec citation de la source | RAG |
| Formation des équipes | Programme par rôles, en intra-entreprise, éligible FUNDAE | Formation |
| Intégration au processus | Le modèle intégré au flux de travail existant | Automatisation |
| Mesure de l'impact | Estimation préalable du retour | Calculatrice de ROI |
Aucune de ces étapes n'exige d'attendre un appel à projets : c'est l'ordre dans lequel il convient de faire les choses, que le projet ait ou non un bono derrière.
Le reste du plan, en une phrase
Les treize autres projets phares couvrent des domaines comme l'infrastructure, la sécurité, l'éducation ou l'administration : de la gigafabrique de calcul à l'Institut de sécurité de l'IA au sein de l'AESIA (l'Agence espagnole de supervision de l'intelligence artificielle). Si cette partie vous intéresse (centres de données, talents, cybersécurité post-quantique), elle est décrite en intégralité dans le document officiel du Plan IA360. Ici, nous poursuivons avec ce qui concerne directement votre projet.
Le bono, en bref : ce qu'il finance et ce qu'il ne finance pas
Le bono empresarial de inteligencia artificial est doté de 600 millions d'euros et s'adresse aux services fournis par des entreprises technologiques européennes, pas à l'achat isolé d'une licence. Le plan prévoit un pilote contrôlé au premier semestre 2027 ; l'appel général, avec ces 600 millions, « antes de final de 2027 » (avant la fin de 2027). Le détail complet du type de projet qui correspond, avec des exemples de processus concrets confrontés au critère littéral du document, se trouve dans quels projets d'IA correspondent au bono IA360 (et lesquels n'y correspondent pas).
Une précision avant de poursuivre : nous ne gérons aucune démarche pour le bono IA360, parce qu'il n'existe aujourd'hui aucune démarche à gérer, et nous ne promettons pas qu'un projet l'obtiendra ni combien il percevrait. Ce que nous faisons, c'est le travail des cinq étapes précédentes, que l'appel à projets existe un jour ou non.
Voir l'IA fonctionner dans votre secteur avant de décider
Dans ce même axe, le plan prévoit un réseau de centres où la tester, et il le formule ainsi : « la empresa ve la inteligencia artificial funcionar en su sector, la prueba con sus datos y la despliega por suscripción » (l'entreprise voit l'intelligence artificielle fonctionner dans son secteur, la teste avec ses données et la déploie par abonnement). C'est, pour l'essentiel, la définition d'une preuve de concept bien menée : on voit d'abord fonctionner, on teste ensuite avec ses propres données, et c'est seulement alors qu'on décide d'y souscrire ou non. Cet ordre (voir, tester, décider) est ce qui évite d'acheter un projet d'IA à l'aveugle, et il n'est pas nécessaire d'attendre l'ouverture d'un centre physique pour l'appliquer. Comment le faire dès aujourd'hui, en risquant le minimum, dans tester l'IA avec vos données avant de la déployer.
Ce que vous pouvez faire dès maintenant, sans attendre l'appel à projets
La méthode que décrit le plan (diagnostic, cas d'usage, pilote, formation, mesure) ne dépend pas de l'existence d'un appel à projets. On peut commencer dès aujourd'hui : le diagnostic et la ligne de base servent à mieux décider, qu'il y ait ou non un appel à projets. Ce qu'exigeront les bases réglementaires, et si ce qui a été fait avant comptera, on ne le sait pas encore. La feuille de route trimestre par trimestre se trouve dans la feuille de route de votre projet d'IA, d'aujourd'hui à 2027 (avec ou sans bono).
Questions fréquentes.
Quelles données faut-il avant de démarrer ?
Cela dépend du cas d'usage, mais presque aucun projet n'échoue à cause du modèle : il échoue à cause des données. Avant de commander quoi que ce soit, mieux vaut savoir dans quel état sont les vôtres, quels processus pourraient vraiment en tirer profit et qui va les maintenir, ce qui est précisément la première chose qu'examine le diagnostic de maturité décrit plus haut.
Qui mesure la ligne de base de productivité ?
C'est à l'entreprise elle-même de le faire, avec des données concrètes (heures, coût, erreurs) avant que le pilote ne démarre. Sans cette photo de départ, il n'y a aucun moyen de démontrer ensuite le moindre impact, que le projet ait ou non un bono derrière.
Faut-il un seul prestataire pour les cinq étapes, ou peuvent-elles être réparties ?
Elles peuvent être réparties, et beaucoup d'entreprises le font : quelqu'un mène le diagnostic et quelqu'un d'autre construit le cas d'usage technique. Ce qu'il ne convient pas de séparer, c'est le diagnostic de la mesure ultérieure : ils doivent utiliser la même ligne de base, sinon, à la fin, personne ne peut démontrer ce qui a vraiment changé.