Développement IA, sécurité et conformité : RGPD, PCI DSS et ISO 27001 en pratique

Une IA a écrit le code : qui est responsable quand il traite mal des données personnelles ? Vous. L'utilisation d'un outil d'IA ne dispense pas l'organisation et ses prestataires de leurs obligations applicables ; la répartition exacte des responsabilités dépend toutefois du cadre juridique, du rôle de chaque acteur et du contrat. Le RGPD, PCI DSS et les autres cadres s'appliquent exactement comme si un humain avait tapé chaque ligne.

C'est le fait que la plupart des acheteurs et des prestataires comprennent de travers dans le développement assisté par IA. La vitesse est réelle, mais elle ne change aucune des règles. La suite parcourt les cadres qu'une entreprise en croissance rencontre le plus souvent, ce que chacun exige vraiment, et pourquoi « c'est l'IA qui l'a écrit » n'est pas, à elle seule, une défense suffisante devant un régulateur ou un auditeur. Lisez-la comme un guide d'évaluation de prestataire, pas comme un conseil juridique ; confirmez les détails avec votre propre conseil ou votre délégué à la protection des données (DPO). Pour la place de la conformité dans la pratique plus large, commencez par le vibe coding et le développement assisté par IA.

La règle que personne ne peut contourner par un prompt

La réglementation encadre des résultats, pas une paternité. Quand votre logiciel stocke l'adresse d'un client, traite un paiement par carte ou gère des dossiers du personnel, l'obligation retombe sur vous, exploitant de ce logiciel, quel que soit l'auteur du code.

Cela compte davantage avec de l'IA dans l'équation, pas moins, parce que le code IA non relu échoue exactement de la manière que les cadres de conformité existent pour empêcher. Le 2025 GenAI Code Security Report de Veracode a constaté que 45 % des échantillons de code générés par IA portaient des vulnérabilités de sécurité connues. Une validation d'entrée manquante ou un identifiant codé en dur est un bug dans n'importe quelle base de code. Dans une base qui traite des données personnelles ou de paiement, le même bug est un manquement de conformité, avec un délai de notification et une amende à la clé. La vitesse de génération ne réduit pas cette exposition ; sauter la relecture l'élargit, comme le détaille notre article sur la sécurité du code généré par IA.

RGPD : le cadre que la plupart des entreprises rencontrent en premier

Le règlement général sur la protection des données (RGPD) encadre le logiciel qui traite des données personnelles ; il s'applique notamment aux organisations établies dans l'Union européenne et, hors UE, lorsque le traitement cible directement des résidents européens ou suit leur comportement, l'analyse dépendant des circonstances du traitement. Si votre application stocke des noms, des e-mails, des adresses ou des comportements, le RGPD s'applique, et l'usage d'une IA pour la construire n'y change rien. En France, l'autorité de contrôle est la CNIL ; en Belgique, l'Autorité de protection des données (APD-GBA).

Deux obligations façonnent la manière dont le logiciel doit être construit. D'abord, la protection des données dès la conception et par défaut : la sécurité et la vie privée doivent être intégrées dès le départ, pas ajoutées après la mise en ligne. L'article 25 du RGPD impose au responsable du traitement d'intégrer des mesures techniques et organisationnelles appropriées dès la détermination des moyens du traitement et pendant celui-ci, avec une protection des données par défaut. Le code IA non relu échoue structurellement à ce test, parce que personne n'a décidé comment les données personnelles seraient protégées ; le modèle a juste produit quelque chose qui tournait. Ensuite, la notification des violations. Au titre de l'article 33, une violation de données personnelles qui présente un risque pour les personnes doit être notifiée à l'autorité de contrôle sans retard injustifié et, si possible, dans les 72 heures (Règlement (UE) 2016/679, article 33, notification à l’autorité de contrôle d’une violation de données à caractère personnel). En France, la CNIL précise qu'une notification initiale doit intervenir dans les meilleurs délais, si possible sous 72 heures, avec justification de tout retard. Une base de code que personne ne comprend rend ce délai brutal : vous ne pouvez pas notifier ce qui s'est passé si personne ne sait lire le code pour le découvrir.

Les enjeux sont volontairement élevés. Pour les violations les plus graves, les amendes du RGPD peuvent atteindre 20 millions d'euros ou 4 % du chiffre d'affaires annuel mondial total, le montant le plus élevé étant retenu (Règlement (UE) 2016/679, article 83). La façon de s'en tenir à l'écart est peu spectaculaire : des données personnelles traitées délibérément, par un code qu'un humain a relu, avec des flux de données documentés assez clairement pour répondre aux questions d'un régulateur.

PCI DSS : dès que vous touchez aux paiements par carte

La norme de sécurité des données de l'industrie des cartes de paiement (PCI DSS) fournit une base d'exigences techniques et opérationnelles visant à protéger les données de paiement ; elle vise les entités qui stockent, traitent ou transmettent des données de porteur de carte, ou qui peuvent influer sur la sécurité de l'environnement de données de carte, les obligations de validation dépendant aussi du programme de conformité applicable. Un commerce d'une seule personne qui encaisse par carte peut ainsi entrer dans le périmètre au même titre qu'une banque. Le PCI Security Standards Council indique que la version active est désormais la v4.0.1 après le retrait de la v4.0 au 31 décembre 2024 ; les nouvelles exigences dont la date d'effet était fixée au 31 mars 2025 sont applicables, mais l'édition, l'exigence concernée et le programme de conformité doivent être vérifiés au cas par cas.

Les exigences de la norme se lisent comme une liste de contrôle que le code IA non relu échoue point par point : chiffrer les données de porteur de carte, restreindre qui peut y accéder, tester régulièrement la sécurité, journaliser et surveiller les accès. Rien de cela n'arrive par accident dans un tunnel de paiement vibecodé. L'architecture la plus sûre est aussi la plus simple à mettre en conformité : ne stockez pas du tout les données de carte vous-même. Faites transiter les paiements par une passerelle de paiement conforme, pour que les détails de carte ne touchent jamais votre base de données, ce qui peut réduire le périmètre PCI sans supprimer automatiquement les obligations applicables : l'effet dépend de l'intégration et doit être confirmé dans l'évaluation PCI concernée. C'est une décision de conception délibérée qu'un humain prend, et exactement le type d'arbitrage qui saute quand personne ne relit la construction. C'est aussi pourquoi les flux de paiement sont une zone à forte relecture dans notre travail de développement e-commerce sur mesure.

ISO 27001 et SOC 2 : quand vos clients vous auditent

Le troisième type d'exigence est différent des deux premiers par nature. Ce n'est pas une loi, mais un cadre par lequel vos clients vérifient que vous sécurisez leurs données avant de vous les confier. Côté européen, la norme de référence est ISO/IEC 27001, la norme internationale de management de la sécurité de l'information : un organisme accrédité audite votre système de management et délivre un certificat portant un numéro et une date d'expiration. Face à un client ou un éditeur SaaS américain, vous rencontrerez plutôt SOC 2, un cadre d'audit de l'American Institute of Certified Public Accountants (AICPA), bâti sur cinq critères de services de confiance : sécurité, disponibilité, intégrité de traitement, confidentialité et vie privée (AICPA). Un auditeur indépendant examine vos contrôles et produit un rapport d'attestation. On ne « réussit » pas SOC 2 ; on reçoit un rapport que vos clients, souvent de plus grandes entreprises qui évaluent un fournisseur ou les outils internes sur mesure dont dépend toute une équipe, lisent avant de vous confier leurs données.

Pour une entreprise logicielle en croissance, ISO/IEC 27001 et SOC 2 peuvent être demandés par certains clients ou marchés comme éléments d'assurance ; leur caractère obligatoire dépend du secteur, du contrat et du contexte commercial, et certains grands clients conditionnent leur signature à la présentation du certificat ou du rapport. Y parvenir repose sur le même socle que les deux premiers cadres. Il faut des contrôles qui existent vraiment, la preuve qu'ils tournent, et une base de code dont un humain peut répondre du comportement. Une attestation bâtie sur une sortie IA non relue est une attestation bâtie sur du sable, parce qu'à l'instant où un auditeur demande comment un contrôle est appliqué dans le code, quelqu'un doit pouvoir lire le code et répondre.

Ce qui relie les trois : un humain qui a lu le code

Les trois familles d'exigences semblent différentes sur le papier et reposent sur le même socle en dessous. Une relecture humaine et une documentation compréhensible facilitent, pour chacune de ces trois familles d'exigences, la démonstration des contrôles et la réponse aux auditeurs ; les textes et référentiels ne formulent pas nécessairement une obligation littérale de lire chaque ligne de code, mais l'absence de relecture rend cette démonstration nettement plus difficile.

C'est pourquoi la relecture n'est pas un agrément de conformité mais la pratique porteuse. Un ingénieur senior qui lit chaque ligne est ce qui transforme « l'application semble marcher » en « nous savons comment les données personnelles circulent, où les données de carte ne vont pas, et quel contrôle applique quelle exigence ». Ce que cette relecture attrape, nous le détaillons dans la relecture humaine du code généré par IA, et l'outillage de sécurité autour, analyse des dépendances à chaque build et le reste, dans comment nous sécurisons chaque construction. Le point pour la conformité est simple : démontrer un contrôle, notifier une violation ou répondre à un auditeur devient nettement plus difficile pour un code que personne n'a lu.

Quoi demander à un prestataire de développement IA sur la conformité

Apportez ces questions à un appel de cadrage et écoutez les précisions.

• Qui est responsable de la conformité dans le contrat ? La réponse honnête vous nomme responsable de traitement et le prestataire sous-traitant, avec des obligations définies, pas une promesse vague que « tout est conforme ».
• Comment les données personnelles sont-elles traitées dans l'architecture ? Vous voulez un flux de données décrit, pas une réassurance. Où les données sont-elles stockées, qui peut les atteindre, et qu'est-ce qui est journalisé ?
• Les données de carte touchent-elles jamais la base de données ? Pour tout ce qui touche aux paiements, la bonne réponse est en général non, avec une passerelle conforme nommée.
• Qui relit le code, et peut-il répondre aux questions d'un régulateur ou d'un auditeur ? Si aucun humain ne peut lire la base de code et expliquer un contrôle, aucune certification bâtie dessus ne vaut quoi que ce soit.
• Où passent mes données quand l'IA génère le code ? Le prestataire envoie votre base de code, et parfois vos données, à un modèle hébergé quelque part. Demandez lequel, sous quel contrat, et si vos données de production y transitent jamais. Un prestataire qui n'a pas la réponse n'a pas lu ses propres conditions d'utilisation, et le RGPD ne s'intéressera pas à cette excuse.

Une précision utile, parce que la confusion est répandue et coûteuse. La CNIL rappelle que le règlement européen sur l'intelligence artificielle (AI Act) vise à encadrer le développement, la mise sur le marché et l'utilisation de systèmes d'IA, et qu'il ne remplace pas le RGPD, qui continue de s'appliquer aux données personnelles traitées pour ou par ces systèmes. Le seul recours à une IA comme outil de développement ne suffit donc pas, à lui seul, à déterminer le champ d'application de l'AI Act, qui dépend notamment de la qualification du système, de ses usages et des rôles des acteurs. Il vise les systèmes d'IA mis sur le marché : si le produit livré embarque lui-même une fonctionnalité d'IA, il tombe dans une catégorie de risque et porte les obligations correspondantes ; si l'IA n'a été qu'un outil de développement, votre logiciel reste un logiciel ordinaire aux yeux du texte. Le RGPD, lui, s'applique dans les deux cas, dès la première donnée personnelle. Un prestataire qui mélange les deux, dans un sens ou dans l'autre, vend de la peur ou de l'insouciance, et aucune ne vous sert.

Notre pipeline de construction complet, du périmètre écrit à la remise relue, est documenté dans comment nous cadrons, construisons et relisons, et il est conçu pour que ces questions aient des réponses claires.

Questions fréquentes

Le code généré par IA est-il conforme au RGPD ?

Pas par défaut, et la conformité n'est jamais une propriété du code seul. Elle dépend de la façon dont le logiciel traite les données personnelles : protection intégrée dès le départ, flux documentés, contrôles vérifiables par un humain. L'IA peut générer un code conforme après relecture par un ingénieur.

Utiliser l'IA pour construire un logiciel supprime-t-il mes obligations de conformité ?

Non, mais l'utilisation d'un outil d'IA ne dispense pas non plus l'organisation et ses prestataires de leurs obligations applicables ; la répartition exacte des responsabilités dépend du cadre juridique, du rôle de chaque acteur et du contrat. Le RGPD et PCI DSS s'appliquent, pour l'essentiel, comme à un logiciel écrit par un humain. « C'est l'IA qui l'a écrit » n'est pas, à elle seule, une défense suffisante devant un régulateur ou un auditeur.

Dois-je être conforme PCI DSS si l'IA a construit mon tunnel de paiement ?

Oui, si le logiciel stocke, traite ou transmet des données de porteur de carte, quel que soit son constructeur ou sa méthode. La voie la moins risquée fait transiter les paiements par une passerelle conforme, pour que les données de carte ne touchent jamais votre base de données.

Un logiciel vibecodé peut-il passer un audit ISO 27001 ou SOC 2 ?

Seulement si les contrôles derrière existent vraiment et que quelqu'un peut prouver qu'ils tournent. Ces audits sont des attestations indépendantes, pas une case à cocher. Un auditeur demandera comment un contrôle est appliqué dans le code, et le code non relu ne laisse personne pour répondre, donc l'attestation échoue.

Quel est le plus grand risque de conformité avec du code IA non relu ?

Qu'une faille de sécurité, du type de celles observées dans 45 % des échantillons de l'étude Veracode de 2025, parte dans un logiciel qui traite des données personnelles ou de paiement. Cela ne signifie pas qu'un bug devient automatiquement une violation : une violation suppose un incident ou une atteinte aux données et une analyse du risque, mais un bug non détecté augmente ce risque, là où une relecture l'aurait attrapé plus tôt.

Comment Globaprom gère-t-il la conformité dans les constructions assistées par IA ?

Les exigences de conformité sont cadrées et chiffrées en amont, les flux de données personnelles conçus délibérément, et un ingénieur senior relit chaque ligne pour rendre les contrôles prouvables. Nous ne sommes pas votre conseil juridique : nous travaillons avec votre avocat ou DPO, pas à leur place.

Construisez-le conforme dès le premier commit

La conformité est la moins chère et la plus sûre quand elle est conçue en amont, pas découverte après la mise en ligne. Dites-nous quelles réglementations votre logiciel doit respecter et nous les cadrerons explicitement, construirons avec chaque ligne relue, et vous remettrons une base de code que vous pourrez réellement assumer devant un régulateur ou un auditeur.

Demander un devis à prix fixe →