Deux calendriers distincts, 22 septembre 2026. Le Règlement européen sur l'IA est une norme en vigueur, avec des obligations qui ne dépendent d'aucun plan national. Le Plan IA360, présenté le 21 septembre 2026, reste sans appel à projets ni bases réglementaires. Cette page n'explique pas le Règlement — c'est l'objet de notre contenu sur l'AI Act — mais plutôt ce qui se construit, au sein d'un projet d'IA, pour y répondre.
Le bono empresarial du Plan IA360 financera des services qui intègrent, selon les mots mêmes du plan, « desarrollo, integración, conocimiento sectorial, tratamiento de datos o rediseño de procesos » (« développement, intégration, connaissance sectorielle, traitement de données ou refonte de processus »), avec une méthode de mise en œuvre qui 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é. Cette méthode — diagnostiquer, documenter un cas, mesurer — n'est pas seulement le critère d'un futur bono : c'est, sous un autre nom, une bonne partie de ce qu'exige un système lorsque sa classification de risque le demande. Un projet bien mené ne sépare pas ces deux choses dans deux dossiers distincts.
Pourquoi l'ordre compte
Les quatre pièces de cette section ne se construisent pas dans n'importe quel ordre, ni avec le même poids selon les projets. L'AI Act s'applique indépendamment du Plan IA360, et l'ampleur de ce qu'il exige dépend de la façon dont chaque système est classé : c'est pourquoi la première pièce — classer — conditionne l'ampleur des trois autres. Un projet qui commence à documenter sans avoir classé au préalable risque de surdimensionner le travail sur des systèmes à risque minimal, ou de rester trop léger sur un système à haut risque.
Quatre pièces qui se construisent dans le projet
Classification du système. Le Règlement ne traite pas de la même façon un système à risque minimal et un système à haut risque, et la différence ne dépend pas de la technologie mais de l'usage concret qui en est fait. Avant de documenter quoi que ce soit, il convient de savoir dans quelle catégorie tombe chaque système : c'est la première étape de l'inventaire technique décrit plus bas, pas un simple filtre réglé dans un formulaire isolé.
Documentation technique. Architecture du système, données avec lesquelles il a été entraîné ou auxquelles il se connecte, métriques de qualité : l'inventaire qui permet ensuite de répondre si quelqu'un demande comment un modèle concret a été construit. Ce n'est pas un document rédigé une fois pour toutes et archivé ; il se met à jour à chaque changement pertinent du système.
Évaluation. Métriques de biais par sous-groupe lorsque le système affecte des personnes, et tests adverses — le même exercice de red teaming dont parle ce guide dans une autre pièce — lorsque le système peut défaillir par manipulation délibérée, et pas seulement par erreur statistique.
Supervision humaine et surveillance. Un registre auditable de ce que le système a décidé et pourquoi, un mécanisme qui alerte si son comportement se dégrade avec le temps, et le point où une personne révise ou valide la décision avant qu'elle n'ait un effet sur un client ou un processus.
De la phase du bono à la pièce technique déjà en construction
Le tableau suivant croise la méthode que le plan décrit pour le bono avec la pièce technique de conformité qui, en pratique, se construit déjà en suivant cette méthode :
| Phase de la méthode du bono (selon le plan) | Pièce technique déjà en construction |
|---|---|
| Diagnostic préalable de maturité | Inventaire et classification des systèmes d'IA en usage |
| Cas d'usage concret | Documentation technique de ce cas : architecture, données, métriques |
| Mesure de l'impact sur la productivité | Système de surveillance et registre auditable sur ce cas |
Cette lecture a une limite qu'il convient de marquer avec précision : à aucun moment le plan ne dit qu'avoir construit cette couche technique accorde une préférence, une priorité ou un avantage formel dans le futur bono. Ce qui est certain, en revanche, c'est que le travail n'est jeté à la poubelle ni dans un cas ni dans l'autre : les données, la documentation et la connaissance du cas d'usage servent aux deux choses à la fois.
Ce que ceci n'est pas
Un projet technique ne certifie pas la conformité à l'AI Act, et il convient de le dire sans détour : Summum IA n'est pas un organisme certificateur. Ce que livre un projet de gouvernance technique de l'IA est la partie laboratoire — inventaire, documentation, évaluation, surveillance — qui soutient ensuite tout processus de conformité plus large, aux côtés de la partie juridique et procédurale qui relève d'une autre discipline.
Questions fréquentes
Faut-il attendre l'appel à projets du bono pour construire tout cela ?
Non. À ce jour, le bono reste sans appel à projets ni bases réglementaires publiées, et cette couche technique répond au Règlement européen, qui a son propre calendrier d'obligations, déjà en vigueur et indépendant du rythme du plan.
Cela suffit-il pour être en conformité avec l'AI Act ?
Pas en soi. La documentation technique, l'évaluation et la surveillance sont la partie qui se construit dans le projet ; la conformité complète inclut aussi des pièces juridiques et procédurales que le seul travail technique ne couvre pas.
Cela s'applique-t-il de la même façon à n'importe quel système d'IA ?
Non. L'ampleur dépend de la classification de risque de chaque système : un assistant à risque minimal n'a pas besoin du travail de documentation d'un système à haut risque. Cette classification est la première étape de l'inventaire technique décrit plus haut, pas une formalité à part.
Où lire ce qu'exige exactement le Règlement européen sur l'IA ?
Dans le contenu déjà publié sur cette norme, à commencer par Régulation de l'IA en Europe.
Projet moteur 11 (axe Diffusion) et projet moteur 4 (axe Sécurité), du Plan IA360 (PDF officiel de La Moncloa). Pour le reste du plan, le guide complet du Plan IA360.
Dernière vérification du contenu : 22 septembre 2026.