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

Une IA a écrit le code : en cas de traitement incorrect de données personnelles, la responsabilité vous incombe. Les obligations de conformité s’attachent au logiciel et à l’entreprise qui l’exploite, jamais à l’outil qui a généré le code. Le RGPD, la norme PCI DSS et les autres réglementations s’appliquent exactement comme si chaque ligne avait été écrite par un humain.

La plupart des entreprises et des prestataires méconnaissent ce principe dans le développement assisté par IA. La rapidité est réelle, mais elle ne modifie aucune règle. Voici les cadres réglementaires les plus fréquents pour une entreprise en croissance, leurs exigences concrètes, et pourquoi l’argument « C’est l’IA qui l’a écrit » ne tient pas face à un régulateur ou à un auditeur. Considérez-le comme un outil d’évaluation des prestataires, non comme un avis juridique : validez les détails avec votre conseiller ou votre délégué à la protection des données (DPO). Pour replacer la conformité dans une approche plus large, commencez par le vibe coding et le développement assisté par IA.

La règle que nul ne peut contourner par une simple instruction

La réglementation encadre les résultats, non leur origine. Que votre logiciel stocke une adresse client, traite un paiement par carte ou gère des dossiers employés, la responsabilité vous revient, en tant qu’exploitant, quel que soit l’auteur du code.

Cette réalité prend encore plus d’importance avec l’IA, car un code non relu échoue précisément là où les cadres de conformité interviennent pour l’éviter. Le 2025 GenAI Code Security Report de Veracode révèle que 45 % des échantillons de code généré par IA contiennent des vulnérabilités connues. Une validation d’entrée manquante ou un identifiant en dur reste un bug dans n’importe quel code. Mais dans un système traitant des données personnelles ou de paiement, ce même bug devient une faille de conformité, assortie d’un délai de notification et d’une amende potentielle. La vitesse de génération n’atténue pas ce risque : l’omettre ne fait que l’amplifier, comme le détaille notre article sur la sécurité du code généré par IA.

RGPD : le premier cadre auquel la plupart des entreprises sont confrontées

Le Règlement général sur la protection des données (RGPD) encadre tout logiciel traitant des données personnelles. Il s’applique notamment aux organisations établies dans l’Union européenne, ainsi qu’à celles hors UE dont le traitement cible des résidents européens ou surveille leur comportement. Si votre application enregistre des noms, des e-mails, des adresses ou des habitudes d’utilisation, le RGPD s’applique, et l’usage d’une IA pour la développer n’y change rien. En France, l’autorité compétente est la CNIL ; en Belgique, l’Autorité de protection des données (APD-GBA).

Deux principes fondamentaux dictent la conception du logiciel. 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 l’origine, et non ajoutées après coup. L’article 25 du RGPD impose au responsable de traitement d’adopter des mesures techniques et organisationnelles adaptées dès la définition des moyens et tout au long du traitement, avec une protection par défaut. Un code généré par IA et non relu échoue systématiquement à ce test, car personne n’a décidé comment protéger les données personnelles : le modèle a simplement produit un résultat fonctionnel. Ensuite, la notification des violations. Aux termes de l’article 33, une violation de données présentant un risque pour les personnes doit être signalée à l’autorité de contrôle sans délai injustifié, et si possible sous 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, idéalement sous 72 heures, avec une justification pour tout retard. Une base de code incompréhensible rend ce délai intenable : impossible de signaler un incident si personne ne peut en analyser le code.

Les sanctions sont volontairement dissuasives. Pour les manquements les plus graves, les amendes du RGPD peuvent atteindre 20 millions d’euros ou 4 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu (Règlement (UE) 2016/679, article 83). La solution pour les éviter est simple : traiter les données personnelles de manière délibérée, avec un code relu par un humain, et des flux documentés assez clairement pour répondre aux questions d’un régulateur.

PCI DSS : dès que vous manipulez des paiements par carte

La norme de sécurité des données de l’industrie des cartes de paiement (PCI DSS) définit un socle d’exigences techniques et opérationnelles pour protéger les données de paiement. Elle s’applique aux entités qui stockent, traitent ou transmettent des données de porteurs de carte, ou qui influencent la sécurité de l’environnement correspondant. Un petit commerce acceptant les cartes est concerné au même titre qu’une banque. Le PCI Security Standards Council indique que la version en vigueur est désormais la v4.0.1, la v4.0 ayant été retirée au 31 décembre 2024. Les exigences différées de la v4 sont obligatoires depuis le 31 mars 2025 : il ne reste aucune période de transition sur laquelle s’appuyer.

Les exigences de la norme ressemblent à une checklist que le code généré par IA et non relu ne remplit pas : chiffrement des données de carte, restriction des accès, tests réguliers de sécurité, journalisation et surveillance des accès. Rien de tout cela ne se produit par hasard dans un tunnel de paiement développé à la hâte. L’architecture la plus sûre est aussi la plus simple à mettre en conformité : ne stockez pas les données de carte. Confiez les paiements à une passerelle conforme, afin que les détails des cartes n’atteignent jamais votre base de données. Votre périmètre PCI se réduit alors à l’intégration plutôt qu’à tout le système. C’est une décision de conception réfléchie, exactement le type de choix qui disparaît quand personne ne relit le code. C’est aussi pourquoi les flux de paiement font l’objet d’une relecture approfondie dans nos projets de développement e-commerce sur mesure.

ISO 27001 et SOC 2 : quand vos clients vous auditent

Le troisième type d’exigence diffère des deux précédents par sa nature. Il ne s’agit pas d’une loi, mais d’un cadre par lequel vos clients s’assurent que vous sécurisez leurs données avant de vous les confier. En Europe, la référence est la norme ISO/IEC 27001, standard international de management de la sécurité de l’information : un organisme accrédité audite votre système et délivre un certificat avec un numéro et une date d’expiration. Face à un client ou un éditeur SaaS américain, vous rencontrerez plutôt le SOC 2, un cadre d’audit de l’American Institute of Certified Public Accountants (AICPA), bâti sur cinq critères de confiance : sécurité, disponibilité, intégrité du traitement, confidentialité et respect de la vie privée (AICPA). Un auditeur indépendant examine vos contrôles et produit un rapport d’attestation. On n’« obtient » pas un SOC 2 : on reçoit un rapport que vos clients, souvent de grandes entreprises évaluant un fournisseur ou les outils internes sur mesure utilisés par leurs équipes, analysent avant de vous confier leurs données.

Pour une entreprise logicielle en croissance, ISO 27001 et SOC 2 arrivent souvent comme une exigence commerciale : un grand compte conditionne sa signature à la présentation du certificat ou du rapport. Leur obtention repose sur les mêmes fondements que les deux premiers cadres : des contrôles réels, des preuves de leur fonctionnement, et un code dont un humain peut expliquer le comportement. Une certification bâtie sur un code généré par IA et non relu est une certification bâtie sur du sable, car dès qu’un auditeur demande comment un contrôle est implémenté dans le code, il faut pouvoir le lire et y répondre.

Ce qui unit les trois cadres : un humain qui a lu le code

Ces trois familles d’exigences semblent distinctes sur le papier, mais reposent sur un même socle. Une relecture humaine et une documentation claire facilitent, pour chacune d’elles, la démonstration des contrôles et la réponse aux auditeurs. Les textes ne mentionnent pas toujours explicitement l’obligation de relire chaque ligne de code, mais son absence complique considérablement cette démonstration.

C’est pourquoi la relecture n’est pas une formalité de conformité, mais une pratique essentielle. Un ingénieur senior qui examine chaque ligne transforme « l’application semble fonctionner » en « nous savons comment circulent les données personnelles, où les données de carte ne vont pas, et quel contrôle répond à quelle exigence ». Ce que cette relecture repère, nous le détaillons dans la relecture humaine du code généré par IA, et les outils de sécurité associés, analyse des dépendances à chaque build, etc., dans notre approche pour sécuriser chaque construction. Le principe pour la conformité est simple : démontrer un contrôle, notifier une violation ou répondre à un auditeur devient bien plus difficile avec un code que personne n’a lu.

Ce qu’il faut demander à un prestataire de développement IA en matière de conformité

Posez ces questions lors d’un appel de cadrage et observez les réponses.

• Qui est responsable de la conformité dans le contrat ? La réponse honnête vous désigne comme responsable de traitement et le prestataire comme sous-traitant, avec des obligations précises, et non une vague promesse de « conformité totale ».
• Comment les données personnelles sont-elles traitées dans l’architecture ? Vous voulez une description des flux, pas des assurances. Où sont stockées les données, qui peut y accéder, et quelles traces sont conservées ?
• Les données de carte atteignent-elles votre base de données ? Pour tout ce qui touche aux paiements, la réponse attendue est généralement « non », avec le nom d’une passerelle conforme.
• Qui relit le code, et peut-il répondre aux questions d’un régulateur ou d’un auditeur ? Si personne ne peut expliquer le code et ses contrôles, aucune certification basée dessus n’a de valeur.
• Où vont mes données quand l’IA génère le code ? Le prestataire envoie votre 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. Un prestataire qui ignore la réponse n’a pas lu ses propres conditions d’utilisation, et le RGPD ne se satisfera pas de cette excuse.

Une précision utile, car la confusion est fréquente et coûteuse. La CNIL rappelle que le règlement européen sur l’intelligence artificielle (AI Act) encadre le développement, la mise sur le marché et l’utilisation des systèmes d’IA, sans remplacer le RGPD, qui continue de s’appliquer aux données personnelles traitées par ou pour ces systèmes. L’AI Act vise les systèmes d’IA commercialisés : si le produit final intègre une fonctionnalité d’IA, il relève d’une catégorie de risque et porte les obligations correspondantes. Si l’IA n’a servi qu’à développer le logiciel, celui-ci reste un logiciel classique aux yeux du texte. Le RGPD, lui, s’applique dans les deux cas, dès la première donnée personnelle. Un prestataire qui confond les deux, dans un sens ou dans l’autre, vend soit de la peur, soit de l’insouciance, et ni l’une ni l’autre ne vous servent.

Notre processus complet, du cadrage à la livraison relue, est détaillé dans notre méthode pour cadrer, construire et relire, et il est conçu pour que ces questions trouvent des réponses claires.

Questions fréquentes

Concevez-le conforme dès le premier commit

La conformité est plus économique et plus sûre quand elle est intégrée dès la conception, et non découverte après la mise en production. Indiquez-nous les réglementations que votre logiciel doit respecter, et nous les cadrerons explicitement, construirons avec chaque ligne relue, et vous livrerons un code que vous pourrez assumer face à un régulateur ou un auditeur.

Demander un devis à prix fixe →