Levée, cession, grand compte : quand on ouvre le code écrit par vos agents

Le 21 octobre 2026, Lovable a publié une mise au point sur ce que couvre sa propre conformité. L’éditeur y écrit qu’elle « ne constitue pas un audit » de l’entreprise de son client ni de son application, que l’organisation cliente « ne devient pas certifiée ISO » en utilisant le service, et que ses responsabilités « dépendent de ce que vous construisez, des données que vous collectez et de la manière dont vous gérez votre activité »[1].

Le principe vaut pour tout outil : hébergeur, base de données, générateur d’applications, agent de code. Leur certification dit comment le fournisseur gère sa propre sécurité. Elle ne dit rien des règles d’accès que votre agent a écrites, ni des secrets qu’il a laissés dans le dépôt. Dans un dossier de levée ou de cession, le logo de conformité d’un fournisseur se présente pour ce qu’il est : une pièce sur le fournisseur.

Notre lecture : les questions portent moins sur l’agent que sur la maîtrise. Six reviennent, que le code ait été écrit à la main ou non.

• À qui sont les comptes. Hébergeur, base, dépôt, nom de domaine, abonnement à l’agent : chacun au nom de la société, avec au moins deux administrateurs, et pas sur l’adresse personnelle d’un fondateur ou d’un prestataire.
• Qui peut déployer. Quelles personnes et quels agents peuvent pousser en production, avec quels jetons, de quelle portée.
• Ce que contient l’historique. L’analyse des secrets de GitHub parcourt « tout l’historique Git, sur toutes les branches » du dépôt[2]. Une clé supprimée au dernier commit reste lisible dans les précédents ; la vraie question est de savoir si elle a été révoquée.
• Qui a écrit et qui a relu. Chez GitHub, l’agent Copilot dans le cloud signe ses commits, avec comme coauteur le développeur qui lui a confié la tâche, et les relie au journal de sa session. Le développeur qui a confié la tâche ne peut pas approuver la demande de fusion (pull request) qui en résulte, et par défaut les workflows ne se déclenchent pas avant la revue[3]. Ce type de trace répond à la question, à condition d’avoir été conservé.
• Qui sait l’expliquer. Pour chaque module sensible, une personne de l’équipe capable d’en décrire le fonctionnement sans relancer l’agent.
• Ce qui se passe en cas de casse. La date de la dernière restauration réellement jouée, et sa durée.

Aucune de ces questions ne demande un outil. Elles demandent des réponses qu’on peut montrer.

Les questionnaires de sécurité des grands comptes s’appuient souvent sur des référentiels publics. Celui de la Cloud Security Alliance, le CAIQ, en est à sa version 4.1 : une série de questions fermées, par oui ou par non, qui documente les contrôles d’un service en nuage[4]. Pour l’IA, la même organisation publie une matrice de contrôles : sa version 1 réunit 243 objectifs répartis en 18 domaines, avec son propre questionnaire téléchargeable gratuitement, et la même page signale une version 1.1 plus récente[5].

Face à une question fermée, il n’y a que trois réponses honnêtes.

Un oui sans pièce reporte la question à la revue technique, où elle revient avec moins de marge. Un non accompagné d’un plan daté se discute. Un oui démenti par la revue fragilise toutes les autres réponses du questionnaire.

Un dossier de sécurité aligne souvent des pièces de nature très différente. Le NIST, dans son guide technique des tests de sécurité, distingue nettement les deux premières[6].

• Le scan automatisé. Un scanner de vulnérabilités s’appuie sur une base de signatures. Il produit des faux positifs et des faux négatifs, ne voit pas les failles qui n’apparaissent qu’en combinant plusieurs attaques, et ses résultats demandent une interprétation humaine[6]. Un scan sans alerte dit seulement : cet outil n’a rien détecté sur ce périmètre, avec cette configuration, ce jour-là.
• Le test d’intrusion. Des évaluateurs imitent des attaques réelles pour contourner les protections d’une application, d’un système ou d’un réseau. La plupart des tests cherchent des combinaisons de failles qui donnent plus d’accès qu’une faille isolée[6]. Il est mené par un prestataire indépendant, sur un périmètre et une période convenus.
• La revue de code. Une lecture humaine du code, sur une version et un périmètre définis. Elle vaut pour ce qui a été lu, et pour rien d’autre.
• La certification ISO/IEC 27001. Elle montre qu’une organisation a mis en place un système de management de la sécurité de l’information, sur un périmètre défini dès la première étape[7]. Elle porte sur la façon de gérer la sécurité, pas sur l’absence de faille dans une application.
• Le rapport SOC 2. Il relève d’une gamme de services que proposent les experts-comptables américains (CPA). L’examen porte sur la description qu’une organisation de services donne de son système et sur ses contrôles, pour les catégories retenues dans la mission parmi cinq : sécurité, disponibilité, intégrité du traitement, confidentialité, vie privée. Le rapport précise lesquelles sont couvertes. Clients et partenaires le demandent souvent[8].

Notre scan se place au premier de ces niveaux. Il est gratuit ; si des vulnérabilités sont détectées, le rapport détaillé est payant. Ce n’est ni un test d’intrusion, ni une certification, et ne pas trouver de faille ne garantit pas leur absence.

Le jour où la revue commence, le temps manque pour produire des preuves. Il reste celui de les ranger. Pour chaque pièce, quatre mentions évitent la plupart des malentendus : le périmètre (quelle application, quelle version, quels environnements), la date, l’auteur, et son indépendance vis-à-vis de l’équipe qui a écrit le code.

Un tableau d’une page suffit : une ligne par pièce, une colonne par mention. Il montre aussi ce qui manque, et c’est souvent l’information la plus utile pour l’équipe elle-même. Une pièce datée d’avant la dernière grande réécriture par un agent se signale comme telle : elle couvre un code qui n’existe plus tout à fait.

Rien de tout cela ne garantit l’absence de faille, et aucun document ne le peut. Ces pièces permettent autre chose : des réponses qui tiennent quand quelqu’un les vérifie.