AI Act 2026 : quelles obligations pour une application IA et sa startup ?

Depuis le 2 août 2026, l'AI Act n'est plus un sujet lointain pour les startups qui créent une application avec de l'intelligence artificielle. Plusieurs obligations de transparence sont désormais applicables. Pour un entrepreneur, la difficulté n'est pas seulement de lire le règlement : il faut déterminer son rôle dans la chaîne, la catégorie de risque du cas d'usage et les écrans ou processus concrets à modifier.

Une application qui résume des notes, un chatbot de support et un outil qui classe des candidatures n'emportent pas les mêmes conséquences. Ils peuvent utiliser le même modèle sous-jacent, mais leur finalité, leurs données et leur influence sur les personnes changent radicalement l'analyse.

Le calendrier du règlement est progressif. Le service officiel de la Commission européenne indique que les exigences de transparence applicables à certains systèmes d'IA sont exécutoires depuis le 2 août 2026. Il prévoit aussi une échéance transitoire au 2 décembre 2026 pour certains fournisseurs de systèmes déjà mis sur le marché avant le 2 août, concernant le marquage et la détection des contenus synthétiques visés à l'article 50, paragraphe 2.

Les échéances futures ne sont pas une permission d'attendre. Une startup qui vise l'emploi, l'éducation, le crédit, certains services essentiels ou d'autres domaines sensibles doit concevoir dès maintenant sa documentation, son contrôle humain et ses traces. Refaire ces fondations après la mise sur le marché coûte davantage.

Le vocabulaire est décisif. Selon l'article 3 de l'AI Act, le fournisseur développe ou fait développer un système d'IA et le met sur le marché ou en service sous son propre nom ou sa propre marque. Le déployeur utilise un système d'IA sous sa propre autorité dans un cadre professionnel.

Utiliser l'API d'un grand fournisseur ne transfère donc pas automatiquement toute la responsabilité. Le fournisseur du modèle documente sa brique ; la startup conçoit la finalité, l'interface, les données, les règles et l'effet sur l'utilisateur. C'est le système complet qui doit être analysé.

Commencez par l'usage prévu, pas par la technologie. Un générateur de descriptions produits et un moteur qui priorise des candidats peuvent appeler le même modèle. Le premier agit sur du contenu commercial. Le second peut influencer l'accès à l'emploi.

• Pratique interdite : certains usages manipulateurs, d'exploitation de vulnérabilités ou de catégorisation sont prohibés.
• Haut risque : cas listés ou liés à des produits réglementés, avec obligations renforcées selon le calendrier applicable.
• Risque de transparence : interaction avec une IA, reconnaissance des émotions, biométrie ou contenus synthétiques dans les situations visées.
• Risque limité ou minimal : usage courant qui reste soumis aux autres règles, contrats et responsabilités.
• Risque RGPD : présence de données personnelles, profilage, décision automatisée ou données sensibles, indépendamment du classement AI Act.

Posez quatre questions : qui subit l'effet de la sortie, quelle décision est influencée, quelle erreur est raisonnablement prévisible et peut-on la corriger humainement avant le dommage ? Si les réponses touchent un droit, un revenu, un accès essentiel ou une sécurité, faites qualifier le cas par un spécialiste.

L'article 50 prévoit plusieurs obligations distinctes. Pour les systèmes destinés à interagir directement avec des personnes, le fournisseur doit concevoir le système afin que les personnes soient informées qu'elles interagissent avec une IA, sauf si cela ressort clairement du contexte pour une personne raisonnablement attentive.

• Afficher l'information au plus tard lors de la première interaction ou exposition.
• Employer une formulation claire, reconnaissable et accessible.
• Ne pas cacher l'information uniquement dans des conditions générales longues.
• Distinguer une assistance IA d'une validation humaine réelle.
• Prévoir l'escalade vers un humain lorsque l'usage et le risque le justifient.
• Conserver une version de l'information affichée avec la version du système.

L'article 50 distingue le marquage technique des sorties et la divulgation visible dans certains contextes. Les fournisseurs de systèmes qui génèrent du contenu synthétique audio, image, vidéo ou texte doivent prévoir un marquage dans un format lisible par machine et détectable comme généré ou manipulé par IA, sous réserve des exceptions prévues.

Les déployeurs qui publient certains deepfakes doivent indiquer leur nature générée ou manipulée. Pour les textes publiés afin d'informer le public sur des questions d'intérêt public, une divulgation peut être requise, avec notamment une exception lorsque le contenu a fait l'objet d'un contrôle éditorial humain et qu'une personne assume la responsabilité éditoriale.

• Inventorier les types de contenu générés par le produit.
• Distinguer génération, simple assistance de mise en forme et modification substantielle.
• Vérifier ce que le fournisseur du modèle marque déjà et ce que votre système doit conserver.
• Prévoir l'affichage visible lorsque le contexte l'exige, en plus du marquage technique.
• Documenter les exceptions utilisées et le processus de contrôle éditorial humain.
• Éviter de supprimer les métadonnées ou signaux de provenance lors des transformations.

L'AI Act ne remplace pas le RGPD. Une application classée à faible risque au titre de l'IA peut encore traiter des données personnelles de façon illégale ou excessive. À l'inverse, minimiser les données aide à réduire plusieurs risques à la fois.

La CNIL recommande une protection des données dès la conception : finalité identifiée, minimisation, vigilance renforcée pour les données sensibles et mesures adaptées dès les choix de conception.

• Définir pourquoi chaque donnée entre dans le système et combien de temps elle reste.
• Identifier la base légale et les informations à fournir aux personnes.
• Vérifier si les prompts et sorties sont conservés par les prestataires.
• Séparer les données de test des données réelles et anonymiser lorsque possible.
• Évaluer la nécessité d'une analyse d'impact sur la protection des données.
• Prévoir accès, rectification, suppression et contestation lorsque ces droits s'appliquent.

Cette documentation n'a pas besoin d'être un dossier juridique lourd au stade du prototype. Elle doit toutefois être structurée et versionnée. Une décision écrite en cinq lignes aujourd'hui évite de reconstruire six mois d'historique lors d'un audit, d'une levée ou d'un incident.

• La tâche exacte confiée à l'IA et la tâche conservée par l'humain.
• Le modèle, sa version ou son identifiant, et le fournisseur utilisé.
• Les données envoyées au modèle et leur éventuelle conservation.
• Le prompt système, les garde-fous et les paramètres importants.
• Dix à cinquante cas de test représentatifs, incluant erreurs et abus.
• La procédure de désactivation ou de retour à une solution sans IA.
• Le coût par action et les limites de débit.
• Le message de transparence et le parcours de recours humain.

Le MVP n'est pas dispensé de sécurité ; il réduit simplement le périmètre. Une fonctionnalité IA plus petite, utilisée par un groupe fermé et surveillée manuellement, produit souvent davantage d'apprentissage avec moins de risque. Le guide création d'un MVP IA détaille les arbitrages modèle, coût et défensabilité.

Une application mobile doit aussi respecter les règles de distribution. Les App Review Guidelines d'Apple imposent notamment une politique de confidentialité accessible, la clarté sur la collecte et le partage des données, ainsi que des mécanismes adaptés lorsque l'application héberge du contenu utilisateur.

La politique Google Play sur les contenus générés par IA rend le développeur responsable des contenus produits par son application et demande des mécanismes permettant aux utilisateurs de signaler les contenus offensants pour les applications génératives couvertes. Ces règles de plateforme s'ajoutent au droit applicable.

• Croire que le fournisseur du modèle porte toute la conformité du système final.
• Afficher « propulsé par l'IA » dans le marketing mais cacher l'information dans le parcours.
• Classer le risque selon la technologie plutôt que selon la finalité et l'effet sur les personnes.
• Conserver tous les prompts et sorties sans finalité ni durée définie.
• Laisser un agent agir sur des systèmes sensibles avec des permissions trop larges.
• Ne pas versionner les modèles, prompts et règles de décision.
• Confondre validation humaine et clic automatique d'un opérateur débordé.
• Attendre l'échéance réglementaire pour commencer la documentation.

Le règlement prévoit des sanctions importantes, avec une prise en compte spécifique de la situation des PME et startups. La peur des plafonds ne doit cependant pas remplacer l'analyse : commencez par le rôle, le risque et les obligations réellement applicables à votre système.

• Jour 1 : cartographier modèles, fournisseurs, clients, utilisateurs et données.
• Jour 2 : écrire la finalité, les usages exclus et votre rôle probable dans la chaîne.
• Jour 3 : réaliser un premier classement de risque et lister les points à faire valider.
• Jour 4 : auditer transparence, consentement, information et recours dans les écrans.
• Jour 5 : tester permissions, conservation, fuites de données et comportements abusifs.
• Jour 6 : créer le registre des versions, la procédure d'incident et l'arrêt d'urgence.
• Jour 7 : faire relire les hypothèses sensibles et prioriser les corrections.

Ce sprint ne certifie pas la conformité. Il transforme un sujet abstrait en backlog de produit vérifiable. Intégrez ensuite les décisions dans votre cahier des charges d'application et dans vos revues de version.

L'AI Act 2026 ne transforme pas chaque application IA en projet juridique impossible. Il oblige en revanche les entrepreneurs à arrêter de traiter le modèle comme une boîte magique ajoutée en fin de sprint. La finalité, la transparence, les données, le contrôle humain et les limites font partie du produit.

Pour construire un MVP IA, commencez petit, documentez les décisions dès la première version et faites intervenir un spécialiste lorsque l'usage influence fortement la vie des personnes. StartupWeek accompagne le cadrage et la construction ; vous pouvez consulter la pédagogie et les formats.

Une application IA digne de confiance n'est pas celle qui cache sa complexité. C'est celle qui rend visibles ses limites, ses responsabilités et ses recours.

Pour un système destiné à interagir directement avec des personnes, l'article 50 prévoit une information, sauf si le caractère artificiel ressort clairement du contexte pour une personne raisonnablement attentive. L'information doit être claire, accessible et fournie au plus tard lors de la première interaction.

Potentiellement oui pour le système d'IA commercialisé sous votre nom, même si vous n'êtes pas fournisseur du modèle. Le rôle exact dépend de la chaîne, de la marque, de la destination et des contrats.

Non. Le classement dépend de l'usage prévu et des catégories définies par le règlement. Une application à faible risque peut toutefois rester soumise à la transparence, au RGPD, aux règles sectorielles et aux politiques des stores.