Sociétés de services informatiques et codage par IA : comment garantir la sécurité lorsque le code est généré par des agents

Pour une société de services informatiques (ESN/Software House), le codage par IA n’est pas seulement une question de productivité interne : c’est un enjeu de fiabilité vis-à-vis du client. Si une équipe utilise des agents pour générer du code, effectuer des refactorings, des tests, des pipelines ou des configurations, elle doit être en mesure de démontrer que la vitesse n’a pas supprimé les revues, la ségrégation des données, les contrôles de sécurité et la responsabilité de livraison.

La question posée par les clients, les services achats et les auditeurs est concrète : comment savez-vous que le code généré ou modifié par IA a été contrôlé avant la livraison ? Une réponse crédible ne peut pas être « nous faisons confiance à nos développeurs » ou « les scanners sont au vert ». Il faut un programme d’assurance : règles internes, preuves, revues, tests, portes de contrôle (gates) dans les pipelines, rapports et remédiations.

Pourquoi le risque est différent pour une société de services

Une équipe interne peut accepter un risque et le gérer dans son propre cycle de développement. Une société de services, en revanche, livre du code à un tiers : le client, l’audit, les achats, le service juridique et l’équipe de sécurité peuvent demander des preuves à tout moment.

L’utilisation du codage par IA soulève de nouvelles questions qui ne concernent pas seulement la qualité technique. Quelles parties ont été générées ou modifiées par des agents ? Quelles données client ont été utilisées dans le prompt ou le contexte ? Quelles dépendances ont été introduites, et qui a révisé le diff ? Quels tests couvrent les autorisations, les rôles et les abus ? Quelles vulnérabilités ont été corrigées avant la livraison et quels risques résiduels ont été communiqués ? Si ces réponses n’existent pas, la société de services perd le contrôle commercial autant que technique.

Politique interne pour l’utilisation de l’IA dans les projets clients

La politique doit établir ce qui est autorisé dans les projets clients, et pas seulement ce qui est pratique pour l’équipe. Elle doit couvrir les outils autorisés, les comptes d’entreprise, les données interdites, les dépôts autorisés, les modes d’agents, le terminal, les agents cloud, les outils externes, les revues et la gestion des exceptions. Les points minimaux à inclure sont :

Aucun compte personnel sur le code ou les données client.
Aucun secret, journal (log) réel ou donnée client dans les prompts non autorisés.
Espaces de travail (workspaces) séparés par client.
Exclusion des fichiers sensibles du contexte de l’agent.
Approbation pour les outils qui lisent les dépôts clients.
Revue obligatoire sur l’authentification, les API, les données, les pipelines et les dépendances.
Traçabilité des parties générées par IA lorsque cela est pertinent pour le contrat.

La politique doit être simple à appliquer : si elle est trop abstraite, chaque équipe l’interprétera différemment et les contrôles perdront leur cohérence entre les projets.

Ségrégation des données client

Le risque le plus délicat n’est pas toujours le bug dans le code, mais le transfert non contrôlé d’informations entre clients, outils et environnements. Une société de services doit séparer les dépôts et les branches, les espaces de travail IDE et les agents, les environnements cloud, les identifiants, les jeux de données de test, les logs et tickets, la documentation client, ainsi que les prompts et transcriptions lorsqu’ils sont conservés.

Un agent travaillant sur plusieurs projets ne doit pas avoir de contexte transversal inutile. Un jeu de données client ne doit pas devenir une fixture réutilisée sur d’autres projets, et une erreur de production ne doit pas être collée dans une discussion générique avec des jetons (tokens), des emails ou des identifiants non expurgés.

Traçabilité : du prompt à la release

Il n’est pas nécessaire de sauvegarder chaque prompt de manière indiscriminée, mais il est nécessaire de savoir quelles décisions ont conduit à la release. Les preuves utiles à conserver incluent les tickets ou tâches d’origine, les PR et commits, les fichiers modifiés par l’IA, les relecteurs et approbations, les scanners et tests exécutés, les nouvelles dépendances, les modifications apportées aux CI/CD, à l’IaC et aux déploiements, les vulnérabilités trouvées et corrigées, ainsi que les risques résiduels acceptés.

Cette traçabilité est également utile en interne : lorsqu’une vulnérabilité apparaît, lorsqu’un client demande des explications ou lorsqu’une régression réapparaît dans une version ultérieure, disposer d’un parcours documenté réduit considérablement les temps de réponse.

Revue obligatoire sur les zones sensibles

Tout le code généré par IA n’a pas le même profil de risque. Une modification de texte ne nécessite pas le même niveau de contrôle qu’une modification de middleware, de rôles, de requêtes, d’API, de pipelines ou de paiements. Une société de services devrait définir les zones qui nécessitent toujours une revue technique :

Authentification, sessions, réinitialisation de mot de passe, MFA, OAuth.
Autorisations, rôles, isolation des tenants, politiques et middleware.
API, requêtes, exports, uploads, paiements et webhooks.
Secrets, logs, gestion des erreurs et configurations.
Dépendances, fichiers de verrouillage (lockfiles), licences, Dockerfiles.
CI/CD, IaC, cloud, IAM et déploiements.
Prompts d’exécution, agents applicatifs, RAG et appels d’outils.

La Code Review devient ainsi une preuve de contrôle : non seulement « nous avons lu le code », mais « nous avons vérifié ces zones, avec ce périmètre et ces résultats ».

Tests et scanners : nécessaires mais pas suffisants

Le SAST, le SCA, le scan de secrets, les tests unitaires et les tests d’intégration sont nécessaires, mais ils ne démontrent pas à eux seuls que l’application respecte la logique métier, les autorisations, l’isolation des tenants et la résistance aux abus. Pour les projets clients, le pipeline devrait produire au moins :

SAST avec triage des nouvelles vulnérabilités.
SCA et scan de licences sur les manifestes et lockfiles.
Scan de secrets sur les dépôts, logs et artefacts.
Tests négatifs sur les rôles, les tenants, les entrées et les modes de défaillance.
Contrôles sur l’IaC, les conteneurs et les configurations.
Preuve de correction et re-test.

Lorsque l’application ou les API sont accessibles par des utilisateurs, des partenaires ou Internet, il est également nécessaire de vérifier le comportement à l’exécution. Dans ce contexte, le Web Application Penetration Testing complète la Code Review : l’un analyse la cause dans le code, l’autre vérifie si le comportement exposé est exploitable sur le système réel.

Dépendances, licences et chaîne d’approvisionnement

Les agents peuvent ajouter des paquets pour finaliser rapidement une fonctionnalité, mais pour une société de services, une dépendance n’est pas seulement un risque technique : cela peut devenir un problème de licence, de maintenance, de vulnérabilités connues, de politique client ou d’audit. Chaque nouvelle dépendance devrait être évaluée en fonction de sa motivation, de sa version et de son lockfile, de sa licence compatible, de son état de maintenance, des vulnérabilités connues, des scripts d’installation et de la présence d’alternatives déjà dans le projet.

Pour les clients grands comptes, la SBOM, la provenance et les rapports SCA peuvent devenir des preuves contractuelles. Même lorsqu’ils ne sont pas explicitement requis, savoir ce qui entre dans la release réduit les temps de réponse en cas de CVE.

Rapports vers le client : que montrer ?

Le client ne doit pas recevoir une narration générique sur l’IA, mais des preuves proportionnées au projet. Un rapport utile peut inclure le périmètre de la release ou de la revue, les parties générées ou modifiées avec l’IA lorsque c’est pertinent, les contrôles effectués avec les scanners et les tests, les vulnérabilités bloquantes corrigées, les vulnérabilités planifiables, les risques résiduels, les nouvelles dépendances, les limites du périmètre et les recommandations pour les versions ultérieures.

Cela ne signifie pas exposer chaque prompt ou chaque détail interne, mais rendre démontrable que le code livré n’a pas été accepté à l’aveugle.

Du projet unique au programme d’assurance

Le véritable saut qualitatif survient lorsque les contrôles ne dépendent pas du chef de projet individuel. Chaque projet utilisant le codage par IA devrait avoir des seuils similaires, des rapports similaires, des portes de contrôle similaires et des responsabilités claires. Le Software Assurance Lifecycle sert précisément à cela : transformer les revues, les tests, les pipelines, la remédiation et le reporting en un processus reproductible sur différentes équipes et différents clients.

Pour une société de services, cela a une valeur commerciale directe : cela aide à répondre aux services achats, aux audits, aux questionnaires de sécurité et aux demandes de preuves sans avoir à reconstruire le processus à partir de zéro à chaque fois.

Checklist pour les sociétés de services utilisant le codage par IA

Politique interne sur l’utilisation de l’IA dans les projets clients.
Outils autorisés, comptes d’entreprise et configurations minimales.
Séparation des dépôts, espaces de travail, données, prompts et identifiants par client.
Interdiction d’insérer des données client, des secrets ou des logs sensibles dans des outils non autorisés.
Traçabilité des PR, commits, revues, scanners, tests et vulnérabilités.
Revue obligatoire sur l’authentification, les API, les données, les pipelines, le cloud et les dépendances.
SAST, SCA, scan de secrets et tests négatifs avec des seuils définis.
Contrôle des licences et des nouvelles dépendances.
Vérification des CI/CD, IaC, conteneurs, déploiements et rollbacks.
Rapport client avec périmètre, preuves, correctifs et risque résiduel.
Remédiation gérée avec responsable, sévérité, SLA et re-test.

Quand impliquer ISGroup

Une société de services peut commencer par une évaluation du processus ou par une vérification sur un projet pilote. Le choix dépend du risque et du niveau de maturité actuel.

Scénario	Risque principal	Contrôle conseillé
Utilisation de l’IA sur plusieurs équipes ou clients	Contrôles non reproductibles et audits difficiles	Software Assurance Lifecycle
PR générée par IA sur code sensible	Vulnérabilités ou régressions dans le code	Code Review
Application ou API exposée aux utilisateurs/clients	Abus à l’exécution et vulnérabilités applicatives	Web Application Penetration Testing
Le client demande des preuves avant la livraison	Périmètre et risque résiduel non démontrables	Programme d’assurance et rapport technique

La valeur ne réside pas seulement dans la recherche de bugs : elle réside dans la capacité à rendre défendable le processus de livraison, en documentant ce qui a été contrôlé, par qui, avec quelles preuves et avec quelles limites déclarées.

Questions fréquentes

Une société de services doit-elle toujours déclarer l’utilisation du codage par IA ?
Cela dépend du contrat, des exigences du client et des politiques internes. En pratique, il est préférable d’être prêt à expliquer quels outils sont utilisés, quelles données sont exclues et quels contrôles vérifient le résultat.
Le client doit-il voir les prompts ?
Pas nécessairement. Les prompts peuvent contenir des informations sensibles. Il est souvent plus utile de fournir la politique, le périmètre, les preuves de revue, les tests, les scanners, les vulnérabilités corrigées et le risque résiduel.
Comment démontrer que le code généré par IA a été contrôlé ?
Avec des preuves concrètes : PR, commits, revues, tests, rapports SAST/SCA, scan de secrets, rapport de dépendances, Code Review, WAPT, vulnérabilités, correctifs et re-tests.
Quand une Code Review indépendante est-elle nécessaire ?
Lorsque le code généré ou modifié par IA touche à l’authentification, aux rôles, aux API, aux données, aux requêtes, aux secrets, aux dépendances, aux pipelines, au cloud ou à la logique métier critique.
Quand le WAPT est-il nécessaire en plus de la Code Review ?
Lorsque l’application est accessible par des utilisateurs ou des clients. La Code Review analyse le code source ; le WAPT vérifie si le comportement exposé est exploitable dans des conditions réelles.

[Callforaction-SAL-Footer]

ISGroup Conseil en Cybersécurité

Codage par IA et sécurité pour les sociétés de logiciels : Programme d’assurance