L’IA Act marque une étape majeure dans la régulation de l’intelligence artificielle en Europe. Ce règlement, adopté en 2024 et progressivement applicable depuis février 2025, vise à concilier innovation et protection des droits fondamentaux. Fondé sur une approche proportionnelle au risque, il impose des obligations adaptées à la criticité des usages et des données. Dans cet article, nous décryptons les principes clés du texte et présentons l’approche “by design” d’Ippon pour transformer la conformité en levier stratégique.
Décryptage de l’IA Act
Le Règlement européen sur l’intelligence artificielle, dit AI Act, a pour objectif de protéger les personnes et les droits fondamentaux tout en permettant le développement et la mise sur le marché de systèmes d’IA.
Le principe central de l’IA Act est la proportionnalité basée sur les risques : les obligations varient en fonction du niveau de risque que le système d’IA fait courir aux individus et à la société. Il s’intègre d’ailleurs dans la continuité de la RGPD dans la mesure où la structure du règlement s’appuie sur la criticité des données décrite dans le RGPD et les exigences pour les systèmes d’IA se renforcent lorsque ceux-ci exploitent des données de plus en plus sensibles.
Le texte de loi a été adopté par l’Union européenne en 2024 et rentre en application de manière échelonnée depuis le 2 février 2025 et jusqu’en 2027, en fonction des technologies et risques tels que décrit dans le règlement. Afin de rendre ce texte de loi crédible pour les industriels, les sanctions prévues vont du retrait du marché et/ou rappel de produits, et des amendes jusqu’à 35 millions d’euros ou 7% du CA annuel mondial de l'entreprise.
Le texte décrit quatre catégories correspondant chacun à un niveau de risque, et il est complété par une catégorie de modèles dits à usage général et correspondant aux LLMs tels que proposés par exemple par les sociétés OpenAI ou Mistral AI.
Ces solutions sont considérées par le règlement comme présentant un risque systémique car elles sont entraînées sur des bases de données très importantes et non spécifiques aux futurs domaines fonctionnels d’exploitation de leurs clients.
Des exigences spécifiques sont décrites pour ces fournisseurs technologiques. Leurs clients exploitant ces modèles devront quant à eux instruire leurs solutions dans les quatre catégories prévues par l’IA Act et qui sont détaillées ci-après.
1. Les risques inacceptables / usages interdits regroupent l’ensemble des cas d’usages et pratiques contraires à la loi et des valeurs de l’Union européenne. Ceci inclut des cas d’usages en applications dans d’autres pays et que l’UE souhaite empêcher d’émerger en Europe. Ces inclus par exemple la notation sociale, la détection d’individus à des fins répressives (vidéo surveillance avec identification des personnes) ou encore l'exploitation de la vulnérabilités des personnes et de leur émotion dans un lieu public. Cette catégorie est déjà entrée en application en février 2025.
2. Les systèmes à haut risque sont ceux exploitant directement des données personnelles sensibles (au sens de la RPGD : par exemple les systèmes biométriques ou recueillant de nombreuses données dans le recrutement), pouvant porter atteinte aux droits fondamentaux (usages répressifs strictement encadrés par la loi) ou encore prenant place dans processus décisionnels importants. Les solutions rentrant dans cette catégorie font l'objet d’exigences obligatoires dont voici les thématiques prévues par le règlement : “données et gouvernance des données, documentation technique, transparence et fourniture d’informations aux déployeurs, contrôle humain [et enfin], exactitude, robustesse et cybersécurité”. Cette catégorie entrera en application le 2 août 2026, l’ensemble des développements et des exigences devant être en règle pour cette date.
3. Les systèmes présentant un risque en matière de transparence regroupent les cas d’usages permettant de simplifier l’accès à l’information (agents conversationnels / chatbots) ou de générer du contenu. Les exigences apportées par le règlement imposent d’informer clairement et directement (= via les interfaces utilisateurs) si le contenu a été transformé ou généré par une IA, ainsi que d’informer sur des possibles limites fonctionnelles et risques associés. Cette catégorie entrera également en application le 2 août 2026.
4. Tous les autres systèmes d’IA présentant un risque minimal restent soumis aux principes généraux et aux bonnes pratiques sans exigences formelles réglementées, et ce à partir du 2 août 2026.
Critères pour déterminer si votre projet est concerné et à quel niveau
Pour savoir si un projet entre dans le champ de l’AI Act et quelle catégorie lui est applicable, il faut répondre à une série de questions opérationnelles. D’abord, identifiez la finalité du système : s’il prend des décisions qui affectent des droits ou des opportunités (recrutement, accès au crédit, sélection médicale, sécurité publique, gestion d’infra), il entre souvent dans la catégorie « haut risque ».
Ensuite, examinez les personnes impactées et l’échelle d’exposition : plus les décisions touchent un grand nombre de personnes ou des populations vulnérables, plus l’exigence de conformité sera élevée.
Vérifiez la nature des données traitées : les données sensibles (santé, origine ethnique, opinions politiques) et les données personnelles à grande échelle augmentent le niveau de risque et déclenchent des obligations spécifiques.
Considérez enfin le mode d’accès et de déploiement : un modèle embarqué sur un équipement critique ou intégré à un processus de production automatisé impose des garde-fous renforcés par rapport à un outil interne d’aide à la décision à usage restreint.
Actions opérationnelles prioritaires et livrables immédiats
La première conséquence opérationnelle est une analyse d’admissibilité réglementaire qui documente la finalité, les personnes impactées, les types de données et l’exposition opérationnelle. Cette analyse est mutualisable avec celle exigée par la RGPD.
La complétude de cette analyse passera aussi par une cartographie et évaluation du risque : elle doit relier l’usage métier aux risques juridiques, de sécurité et d’éthique.
La documentation doit être structurée et disponible : fiches de conception, provenance des jeux de données, registres de versions et de technologies IA utilisées, ou encore logs d’inférence dans le cas où vous entraînez vous même votre modèle d’IA.
Sur le plan technique, il faut sécuriser la chaîne d’approvisionnement et les interfaces. Ceci doit être mis en œuvre de manière adaptée à votre architecture, incluant des thématiques récurrentes devant être considérées tels que les contrôles d’accès aux modèles, hachage ou signature des artefacts, mécanismes d’isolation pour les composants tiers et règles claires sur l’envoi de données à des services externes.
De par la nature non prédictible de ces technologies, de nouveaux tests sont à prévoir : tests de robustesse, tests d’impartialité et scénarios de red teaming.
Enfin une surveillance continue en production pour détecter dérives et attaques adverses sont à prévoir au sein de vos solutions d’observabilité et de surveillance continue.
Ces mesures seront à adapter avec votre montée en maturité sur cette réglementation et le niveau de risque de votre solution. L’IA Act prévoit des cas spécifiques et/ou les solutions considérées à hauts risques qui déclenchent des obligations supplémentaires fonctionnelles et techniques.
L’approche Ippon pour répondre à l’IA Act “by design”
La France, puis l’Europe sont pionnières dans la réglementation des usages informatiques à l’échelle européenne et l’intelligence artificielle en fait désormais partie. Chez Ippon, nous pensions déjà que la RGPD et la CSRD n’avaient pas pour simple objectif d’imposer des contraintes légales, mais étaient bien une opportunité stratégique pour les directions technologiques. L’IA Act est une suite logique, compatible et sur-mesure pour les solutions d’IA.
La logique fondée sur le risque par l’AI Act interdit certaines pratiques dangereuses et impose des obligations renforcées particulièrement pour les systèmes qualifiés à « haut risque ». Cette orientation nous permet d’itérer dans nos réflexions sur nos pratiques d’ingénierie et de gouvernance afin d’articuler robustesse, traçabilité et création de valeur métier.
A l’instar de tout projet, un projet IA bien aligné commence par une définition précise de la finalité, une cartographie des publics impactés et une évaluation de la sensibilité des données. À défaut, la technique risque de produire des résultats conformes mais dénués d’usage réel pour le métier et entraînant des déceptions voire l’abandon prématuré de la solution (et donc un ROI négatif). A l’inverse, une gouvernance efficace permet de prioriser les cas d’usage à haut apport et de limiter les efforts sur des expérimentations peu stratégiques.
Déjà initiée avec la RGPD,, nous pensons que la gouvernance, humaine et éclairée, doit devenir le pivot de toute démarche IA. La réglementation impose des preuves documentées tout au long du cycle de vie — cartographies des risques, documentation des jeux de données, enregistrements des versions de modèles, tests reproductibles et dispositifs de surveillance en production — et ces exigences doivent être intégrées et prévues dès la phase de cadrage. En effet, la génération continue et fluide de ces preuves doit être intégrée au design global afin que celle-ci soit marginale en effort d’exploitation et maintenable par les équipes.
Nous mettons la qualité logicielle au centre de nos propres usages de l’intelligence artificielle avec le Prompt Driven Development. Ainsi, qualité et traçabilité sont des leviers opérationnels concrets pour transformer la conformité de nos clients en avantage compétitif avec des outils et bonnes pratiques (on peut citer la systématisation des architectures hexagonales et de l’approche Craft) sur lesquels sont formés nos consultants.
Mettre en place des pipelines MLOps robustes réduit la dette technique, facilite les audits et accélère la remédiation lors d’incidents. Nous observons que des modèles déployés sur des bases de code propres et testées présentent moins d’hallucinations et sont plus faciles à expliquer aux parties prenantes ; c’est un point essentiel pour démontrer la maîtrise du modèle devant des auditeurs ou des métiers exigeants.
La maîtrise de la chaîne d’approvisionnement est, à nos yeux, un autre sujet central. L’utilisation de modèles pré-entraînés ou d’API externes requiert une due diligence systématique sur la posture de sécurité des fournisseurs, le contrôle des flux de données et des clauses contractuelles claires sur l’usage des données. Nous avons l’habitude de réaliser nos arbitrages “build versus buy” qui ne se limitent pas au coût immédiat mais prennent en compte la provenance des modèles, la possibilité de hachage et de signature des artefacts, ainsi que la conformité géographique des traitements. Pour des données classifiées, le recours à des services hébergés hors de l’Union européenne pose des risques juridiques et opérationnels qu’il faut intégrer au plan de décision.
Sur le plan économique, l’AI Act pousse vers une rationalisation qui favorise la mise en place d’une chaîne MLOps mutualisée. Cette chaîne est généralement intégrée au sein d’une plateforme cloud et s’inscrit alors dans les approches plateformes et modernisation. Ensemble, ce cadre technologique permet de répondre aux exigences de l’IA Act, en plus de réduire de moitié les efforts humains, diminuer le time-to-market et améliorer la maîtrise des coûts, notamment le coût du compute.
En février 2025, le CLUSIF publiait sa Politique de Sécurité des Systèmes d’Information (PSSI) pour l’Intelligence artificielle. Nous adhérons aux pratiques recommandées par cet organisme qui vont dans le sens de celles recommandées dans cet article. Une dernière conviction Ippon consiste à toujours conserver l’humain au cœur de la validation des contenus générés par l’IA. Notre métier de développeur évolue pour devenir un expert dirigeant l’IA pour développer plus rapidement, mais en imposant à l’IA un cadre qualitatif rigoureux.
Le développeur expert reste une ressource essentielle aux entreprises afin de garantir cette qualité; Et être capable de créer le code manuellement dans les cas où vos besoins spécifiques ne sauraient être traités par des IA pré-entrainés, car celles-ci restent entraînées sur des modèles de code répondant à des cas d’usages génériques !
Conclusion
Nos convictions se traduisent par des pratiques concrètes : placer le métier au cœur du projet, arbitrer en faveur de technologies éprouvées pour les fonctions critiques, imposer des standards de qualité logicielle, et industrialiser les pratiques MLOps pour garantir traçabilité et sécurité. Chez Ippon, nous pensons que ces choix ne sont pas antagonistes à l’innovation ; au contraire, ils créent un terrain favorable où l’IA peut délivrer des résultats fiables et mesurables pour le business. L’exigence réglementaire devient ainsi un cadre qui ordonne les priorités et évite les expérimentations coûteuses et non reproductibles.
Enfin, nous considérons que l’approche proactive est indispensable. L’AI Act entre en vigueur dans une temporalité que les DSI doivent anticiper en combinant audits d’usage, priorisation des cas, MVP de plateforme MLOps et programmes de montée en compétence. Chez Ippon, notre doctrine est claire : la conformité intelligente et technique est aujourd’hui le socle de création de valeur. Les directions technologiques qui intégreront ces principes tireront un avantage durable en qualité, en coût et en confiance des métiers, transformant une contrainte réglementaire en moteur d’excellence opérationnelle.
