De plus en plus de fournisseurs déclarent utiliser l’IA pour développer des logiciels plus rapidement : assistants de codage, agents, générateurs de tests, outils de revue, automatisations de pipelines. Pour ceux qui achètent des logiciels, cette information n’est pas négative en soi — cela peut être un réel avantage si le fournisseur contrôle correctement les données, le code, les dépendances, les tests et la livraison.
Le risque survient lorsque « nous utilisons l’IA » devient une promesse commerciale sans preuves. Les services achats, CTO, CISO et juridiques doivent demander des preuves : quels outils sont utilisés, quelles données entrent dans le processus, quels contrôles vérifient le code et que se passe-t-il si une vulnérabilité apparaît. La due diligence ne doit pas bloquer le fournisseur : elle doit permettre de distinguer ceux qui utilisent l’IA de manière gouvernée de ceux qui ont simplement accéléré le développement en transférant le risque sur le client.
La bonne question n’est pas « utilisez-vous l’IA ? »
Demander simplement si le fournisseur utilise l’IA produit une réponse peu utile. La question correcte est : à quelles étapes du cycle de développement l’IA est-elle utilisée et avec quels contrôles ? Les domaines peuvent être très différents les uns des autres — de la génération de code applicatif au refactoring, de l’écriture de tests à l’analyse de logs et de rapports de bugs, de la génération de pipelines et d’IaC à la suggestion de dépendances, jusqu’à la revue de code assistée, la documentation et les agents qui ouvrent des pull requests ou exécutent des commandes.
Chaque usage a un profil de risque différent. Un assistant qui suggère du texte pour la documentation n’équivaut pas à un agent qui modifie des autorisations, des requêtes, des pipelines et des dépendances : les traiter de la même manière revient à sous-estimer les risques réels.
Quelles données client entrent dans les outils d’IA ?
Le premier domaine de due diligence concerne le traitement des données (data handling). Le fournisseur peut avoir besoin de logs, de tickets, de dépôts, de dumps, de payloads, de captures d’écran ou de documentation pour résoudre des problèmes. Si ces éléments entrent dans des prompts, des chats, des agents ou des outils non autorisés, le client perd le contrôle sur ses données et ses secrets.
Les questions à poser concernent la possibilité pour le fournisseur d’insérer du code client dans les outils d’IA, s’il peut insérer des logs, des tickets, des données personnelles ou des données de production, s’il utilise des comptes entreprise ou des comptes personnels, s’il existe des règles de rédaction (redaction), si les prompts ou transcriptions sont conservés, si les données sont utilisées pour l’entraînement ou l’amélioration du service, et s’il existe des restrictions contractuelles sur les sous-traitants et les outils. La réponse doit être documentée, et non reposer sur des assurances verbales.
Quels contrôles existent sur les PR générées ou assistées par IA ?
Le client ne doit pas demander chaque détail opérationnel, mais doit comprendre si le code généré par l’IA est accepté aveuglément. Les preuves utiles incluent la politique interne du fournisseur sur le codage par IA, la présence de protection de branches (branch protection) et de revues obligatoires, des exemples de flux de PR, des CODEOWNERS ou relecteurs pour les zones sensibles, la traçabilité des commits et des releases, des rapports de revue de code et des critères de blocage de fusion (merge).
Les domaines qui nécessitent une revue approfondie sont l’authentification, les autorisations, les API, les requêtes, les données, les paiements, les secrets, les dépendances, les pipelines, le cloud et la logique métier. Si le fournisseur ne sait pas expliquer comment il les contrôle, le risque reste à la charge du client.
Tests, scanners et remédiation : quelles preuves existent ?
Un fournisseur peut déclarer utiliser le SAST, le SCA, le scan de secrets et des tests automatiques. La question suivante est de savoir ce qu’il advient des résultats (findings) : quels scanners sont exécutés et quand, quels niveaux de sévérité bloquent la release, qui effectue le triage, comment sont gérés les faux positifs et les dérogations, quels tests négatifs couvrent les rôles, les tenants, les entrées et les abus, comment un correctif est vérifié et quels rapports sont partagés avec le client.
Les scanners et les tests ne remplacent pas une vérification indépendante, mais sont un signal de processus. Si le fournisseur ne produit pas de rapports ou n’a pas de SLA de remédiation, les contrôles risquent de n’être que formels.
Dépendances, licences et chaîne d’approvisionnement
L’IA peut suggérer des bibliothèques, des plugins, des actions, des images de base de conteneurs et des outils de build. Pour le client, cela impacte les vulnérabilités, les licences, la maintenance, l’audit et le verrouillage (lock-in). Les preuves à demander comprennent la liste des dépendances principales, l’analyse de composition logicielle (SCA), le rapport de licences, l’SBOM lorsque le périmètre le requiert, la politique sur les nouvelles dépendances, le pinning des versions et des actions, la gestion des CVE, ainsi que la provenance et l’intégrité des artefacts.
Une dépendance peut être techniquement pratique mais inacceptable selon la politique du client. Cela doit être découvert avant la livraison, pas lors d’un audit.
Secrets, environnements et accès
La due diligence doit vérifier comment le fournisseur gère les identifiants, les environnements et les données de test. Les points à clarifier concernent l’utilisation de données synthétiques ou réelles, la protection des fichiers de configuration, des clés API, des jetons cloud et des secrets de webhook, si les identifiants sont personnels ou nominatifs par projet, la séparation entre staging et production, qui peut accéder aux environnements client, la présence de logs d’accès et de révocation, et ce qui se passe lorsqu’un collaborateur quitte le projet.
Si une clé client finit dans des prompts, des logs ou des dépôts, le contrat doit prévoir la notification, la rotation, l’analyse d’impact et des responsabilités claires.
Clauses techniques à insérer ou vérifier
Les clauses génériques sur les « bonnes pratiques » ne suffisent pas. Pour les fournisseurs qui développent avec l’IA, il faut des exigences plus concrètes, couvrant les outils d’IA autorisés et les sous-traitants, l’interdiction ou les limites sur les données client dans les prompts, l’obligation d’utiliser des comptes d’entreprise avec des contrôles de type entreprise, la ségrégation entre les clients, la revue humaine sur les zones sensibles, les scans et tests minimaux, la gestion des dépendances et des licences, la divulgation des vulnérabilités et incidents, les SLA de remédiation, le droit d’audit ou de vérification indépendante et la remise de rapports, SBOM ou preuves lorsque demandé.
Les services juridiques et achats ne doivent pas rédiger seuls les contrôles techniques : ils doivent traduire les exigences techniques en obligations vérifiables.
Quand une vérification indépendante est-elle nécessaire ?
La due diligence documentaire est utile, mais pas toujours suffisante. Si le logiciel est critique, exposé, multi-tenant, intégré à des systèmes d’entreprise ou traite des données réelles, une vérification technique allant au-delà de la documentation fournie par le fournisseur lui-même est nécessaire.
La vérification indépendante peut inclure une Revue de Code sur le code livré, l’authentification, les API, les secrets, les dépendances et les pipelines ; un Test d’Intrusion d’Application Web sur les applications ou API exposées ; et une vérification de processus avec le Cycle de Vie d’Assurance Logicielle si le fournisseur travaille de manière continue. Le but n’est pas de dupliquer tout le travail du fournisseur, mais de vérifier les points où une erreur aurait un impact direct sur le client.
Checklist de questions pour le fournisseur
- Quels outils d’IA utilisez-vous dans le développement ?
- À quelles étapes : code, tests, revue, pipeline, documentation ?
- Quelles données client peuvent entrer dans les prompts ou le contexte ?
- Utilisez-vous des comptes entreprise, SSO, MFA et journalisation (logging) ?
- Le code ou les prompts peuvent-ils être utilisés pour l’entraînement ou l’amélioration du service ?
- Comment séparez-vous les clients, les dépôts, les espaces de travail et les environnements ?
- Quels contrôles bloquent les fusions (merge) et les releases ?
- Quelles zones nécessitent une revue humaine obligatoire ?
- Quels scanners exécutez-vous et quels rapports partagez-vous ?
- Comment gérez-vous les dépendances, les licences, les SBOM et les CVE ?
- Comment protégez-vous les secrets et les identifiants client ?
- Quels SLA avez-vous pour la remédiation et le retest ?
- Acceptez-vous une vérification indépendante avant la mise en production ou l’acceptation finale ?
Signaux d’alarme
- Le fournisseur ne parle que de productivité, pas de contrôles.
- Il ne sait pas dire quels outils d’IA il utilise.
- Il utilise des comptes personnels ou des plans gratuits sur du code client.
- Il n’a pas de règles sur les données et les prompts.
- Il ne produit aucune preuve de revue, de test ou de scan.
- Il ne distingue pas le code généré du code révisé.
- Il ne contrôle pas les licences et les dépendances.
- Il n’accepte pas de vérifications indépendantes sur les périmètres critiques.
- Il n’a pas de SLA de remédiation.
- Il ne sait pas qui est responsable en cas de vulnérabilité.
Quand impliquer ISGroup
ISGroup peut soutenir la due diligence technique avant la signature, lors de l’acceptation d’une release ou avant la mise en production. La meilleure vérification est proportionnée : il n’est pas nécessaire d’avoir le même niveau de contrôle pour un outil interne à faible risque et pour une plateforme exposée traitant des données personnelles, des rôles et des API.
| Scénario | Risque principal | Contrôle conseillé |
|---|---|---|
| Code livré ou PR critiques | Vulnérabilités ou régressions dans le code | Revue de Code |
| Web app ou API exposées | Abus applicatif depuis l’extérieur | Test d’Intrusion d’Application Web |
| Fournisseur continu ou développement récurrent | Processus non vérifiable dans le temps | Cycle de Vie d’Assurance Logicielle |
FAQ
- Est-il risqué de choisir un fournisseur qui utilise l’IA ?
- Pas nécessairement. Il est risqué de choisir un fournisseur qui utilise l’IA sans politique, preuves, revues, tests, gestion des données et responsabilités claires.
- Dois-je demander à voir tous les prompts ?
- Pas toujours. Les prompts peuvent contenir des informations sensibles du fournisseur lui-même. Il est généralement plus utile de demander les politiques, les rapports de revue, les scanners, les tests, les SBOM, les correctifs apportés, les clauses contractuelles et le droit d’audit.
- Quel document demander en premier ?
- Une politique ou une description du processus de codage par IA du fournisseur : outils utilisés, données interdites, revues obligatoires, contrôles techniques, gestion des dépendances et SLA de remédiation.
- Quand une revue de code indépendante est-elle nécessaire ?
- Lorsque le code livré touche à l’authentification, aux API, aux données, aux secrets, aux requêtes, aux dépendances, aux pipelines, au cloud ou à une logique métier critique.
- Quand un test d’intrusion d’application web est-il nécessaire ?
- Lorsque l’application ou l’API est exposée à des utilisateurs, clients, partenaires ou à Internet, et qu’elle gère des données réelles, des rôles, des téléchargements, des paiements ou des intégrations.
[Callforaction-CR-Footer]
Leave a Reply