Vous intègres Daybreak ou Mythos dans votre stack. Votre auditeur ISO 27001 ou SOC 2 va vous poser trois questions : pourquoi cet outil, comment vous le contrôles, où sont les preuves. Si vous n'avez pas les réponses prêtes, votre rapport d'audit va vous coûter du temps inutile. Voici exactement ce qu'il faut produire — par contrôle.
ISO 27001:2022 — les 4 contrôles directement concernés
A.5.23 — Sécurité de l'information dans les services cloud
Daybreak (OpenAI) et l'accès à Mythos via partenaires (CrowdStrike, etc.) sont des services cloud externes. Le contrôle A.5.23 vous demande de :
- Documenter le service utilisé (Daybreak en pilote sur tel repo, par tel·le ingé·e, depuis telle date).
- Définir les exigences sécurité côté fournisseur (DPF, SCC, training opt-out, data residency).
- Avoir un mécanisme de revue régulière du service (annuelle minimum).
Preuve attendue : politique d'usage des services IA externes + revue 2026 documentée + extraits du DPA.
A.5.19 et A.5.20 — Sécurité dans les relations fournisseurs
Les contrats fournisseurs doivent couvrir le périmètre, la confidentialité, la rupture, la conformité réglementaire.
Preuve attendue : DPA signé avec OpenAI ou avec le vendor Glasswing (si Mythos via Palo Alto par exemple) + clauses spécifiques sur le traitement du code et la non-utilisation pour entraînement + droit d'audit.
A.8.16 — Surveillance des activités
Si Daybreak est utilisé sur du code prod, son activité doit être logguée et surveillée. Pas seulement "le service tourne", mais "qui l'a utilisé, sur quel code, avec quel résultat".
Preuve attendue : extraits de logs proxy entreprise montrant les requêtes vers Daybreak, par utilisateur, par périmètre. Idéalement intégrés dans votre SIEM.
A.8.28 — Codage sécurisé
Daybreak peut proposer des patches. Avant d'intégrer ses suggestions, vous devez avoir une procédure de validation humaine — sinon vous perds la maîtrise du code que vous mets en prod.
Preuve attendue : procédure "patch suggéré IA → revue par X → tests automatisés → merge". Pas de merge automatique sans humain.
SOC 2 — les Trust Services Criteria concernés
CC9.2 — Vendor management
Identique à A.5.19/20 ISO. SOC 2 demande de surcroît une classification du risque du vendor. OpenAI / Anthropic sur du code production = risque élevé. Donc due diligence renforcée, revue annuelle, plan B en cas de défaillance.
Preuve attendue : fiche vendor avec scoring de risque + plan de contingence (que faire si Daybreak tombe ou si on doit le remplacer rapidement).
CC6.1 — Logical access
Qui chez vous a accès à l'API Daybreak ? Liste nominative, principe du moindre privilège, MFA obligatoire sur le compte OpenAI enterprise.
Preuve attendue : extraits de la console admin OpenAI montrant les utilisateurs et leurs rôles.
CC7.2 — System monitoring
Détection des anomalies dans l'usage de Daybreak (un dev qui scanne 50 repos d'un coup à 3h du matin = signal faible).
Preuve attendue : alerting SIEM sur usages anormaux + rapport d'incident s'il y a eu des cas en 2026.
CC2.2 — Quality of communication / change management
Quand vous ajoutez Daybreak à votre stack, c'est un changement significatif à communiquer en interne et à documenter.
Preuve attendue : ticket de change management + communication interne + mise à jour du registre des outils.
Le dossier type à monter (1 jour de travail)
Si vous pars de zéro, voici ce que vous produis :
- Note de cadrage (1 page) : pourquoi vous introduis Daybreak/Mythos, périmètre, objectifs, durée du pilote.
- Risk assessment (2 pages) : risques identifiés (transfert US, dépendance fournisseur, fiabilité output, etc.) + mesures d'atténuation.
- DPA enterprise + avenants négociés (contrat OpenAI ou contrat vendor Mythos).
- Politique d'usage interne (1 page) : qui, quoi, comment, logs, sanctions. Voir GPT-5.5-Cyber : ce que votre DSI doit cadrer.
- Procédure de revue annuelle (1 page) : date, responsable, points à revoir, ré-évaluation du risque.
Ces 5 docs te couvrent en audit. Un auditeur expérimenté te demandera principalement ces éléments — le reste, c'est de la traçabilité opérationnelle (logs, tickets).
Le piège du "on l'a juste essayé"
J'ai vu deux audits ISO en 2026 où la boîte avait "juste testé" un outil IA externe sans le déclarer ni le cadrer. À chaque fois, l'auditeur l'a identifié dans les interviews tech et l'a écrit dans le rapport comme non-conformité majeure (article SoA non couvert, vendor non assessé). Le passage de "test discret" à "outil non déclaré utilisé en production" est très rapide quand un dev trouve ça utile.
Donc la règle simple : si un outil traite du code, des logs ou des données client (même en pilote, même 5 minutes), il rentre dans votre inventaire fournisseurs dès la première utilisation. Voir aussi SOC 2 Type II pour clients enterprise.
L'angle "audit AI Act" qui arrive en plus
Au 2 août 2026, les obligations AI Act sur les systèmes "haut risque" s'appliquent. Daybreak n'est pas en soi haut risque pour la plupart des usages, mais si vous l'utilisez pour évaluer du code dont la défaillance peut affecter des personnes (santé, finance, infra critique), vous retombez dans le scope. Voir AI Act et Daybreak / Mythos : haut risque ou pas ?.
Donc voilà : Daybreak et Mythos sont auditables ISO et SOC sans difficulté, à condition d'avoir le dossier fait avant que l'auditeur le demande. Un jour de travail bien fait vous évite 3 jours de remédiation post-audit.
