Sécurité & confiance chez OpsCodex

OpsCodex est déployé en mono-tenant, on-premise, dans votre propre environnement. Vos documents et modèles de processus ne sont stockés que dans votre environnement. Ils ne sont transmis à un modèle d’IA que là où vous le décidez — et, si vous le souhaitez, uniquement au sein de votre propre réseau. Il n’existe aucun plan de données partagé entre clients.

Docker Compose sur un serveur

L’application entière tourne avec Docker Compose sur un seul serveur. Un petit serveur suffit pour un pilote ; les prérequis, la routine de sauvegarde et le déroulé des mises à jour figurent sur la page Évaluer OpsCodex.

Kubernetes avec un chart Helm

Le chart installe OpsCodex dans un seul namespace et ne demande aucun droit à l’échelle du cluster. Chaque conteneur tourne sous un utilisateur non root avec un UID fixe, sur un système de fichiers racine en lecture seule, sans aucune capability Linux ; le chart est testé avec le standard Pod Security restricted imposé sur son namespace. PostgreSQL et le stockage compatible S3 viennent de votre plateforme, ou tournent en conteneurs dans le même namespace — notre propre image de base de données, qui fonctionne sans root, et un serveur S3 sous licence Apache 2.0. Le trafic l’atteint par votre Ingress ou la Gateway API.

Contrôle d’accès par rôles

Des rôles granulaires reflètent le workflow de gouvernance — auteur, relecteur, approbateur, administrateur, auditeur et éditeur de documentation. Chacun voit et fait exactement ce que son rôle permet, et rien de plus.

Authentification unique (SSO)

La connexion via votre fournisseur d’identité (OIDC, SAML) est en cours de développement. D’ici là : comptes locaux avec règles de mot de passe conformes au NIST, verrouillage après des échecs répétés et déconnexion après inactivité.

Mots de passe

Les règles de mot de passe suivent la norme NIST SP 800-63B-4 : au moins 15 caractères par défaut — ce que la norme exige d’un mot de passe qui est le seul facteur de connexion —, sans classes de caractères imposées ni changement périodique forcé. Les mots de passe courants ou divulgués sont refusés, vérifiés contre une liste livrée avec le produit ; la vérification ne fait donc aucun appel sortant. Dix échecs de connexion consécutifs verrouillent le compte pendant 15 minutes pour l’adresse d’où ils proviennent (les deux valeurs sont réglables), si bien qu’un tiers ne peut pas bloquer son titulaire. Les mots de passe sont stockés hachés à sens unique (bcrypt) ; en changer exige le mot de passe actuel et met fin aux sessions existantes.

Sessions

Les sessions utilisent des cookies à durée de vie courte, HttpOnly et Secure, et prennent fin après une période d’inactivité — deux heures par défaut, réglable par un administrateur —, ce que le serveur vérifie à chaque requête. Déconnexion, désactivation et changement de rôle prennent effet immédiatement.

Portail des collaborateurs

Le portail en lecture seule, où les collaborateurs consultent les processus approuvés, est soit ouvert à toute personne qui l’atteint depuis votre réseau, soit — par un réglage administrateur — réservé aux utilisateurs connectés. Il ne montre que des versions publiées : brouillons et travaux en cours n’y figurent jamais.

Accès pour les agents IA

Un point de terminaison en lecture seule via le Model Context Protocol (MCP) permet à des agents IA de lire les processus approuvés, chaque réponse avec sa révision, son approbateur et sa date de publication. Il reste désactivé tant qu’il n’est pas activé dans la configuration de l’installation. Chaque client a besoin de son propre jeton, émis et révocable par un administrateur ; le point de terminaison n’offre aucune opération d’écriture, et chaque accès est journalisé.

En transit

Tout le trafic est chiffré avec TLS moderne ; les suites cryptographiques faibles ne sont pas proposées.

Au repos

Les secrets applicatifs — comme les clés des fournisseurs d’IA — sont chiffrés en AES-256-GCM, et les mots de passe des comptes sont hachés à sens unique. En déploiement on-premise, vous détenez vous-même l’ensemble du matériel cryptographique.

Fichiers téléversés

Les contenus téléversés par les utilisateurs sont servis en téléchargement avec le MIME-sniffing désactivé, afin que des fichiers non fiables ne puissent pas s’exécuter dans le navigateur.

Les actions de gouvernance sont écrites dans une piste d’audit en append-only. C’est imposé au niveau de la base de données, pas dans le code applicatif : un trigger sur la table d’audit rejette chaque UPDATE et DELETE, et le rôle base de données sous lequel tourne l’application s’est vu retirer ces droits. L’application ne peut pas réécrire son propre historique d’audit, même compromise — seul le rôle de migration distinct, utilisé pour les changements de schéma et le démontage des tests, le peut, et ce rôle ne sert jamais une requête.

Pour être précis sur la limite : le trigger couvre la modification et la suppression au niveau des lignes. Il ne couvre pas TRUNCATE, et il ne protège pas contre quelqu’un disposant d’un accès superutilisateur à votre propre serveur de base de données — aucun contrôle applicatif ne le peut. Considérez la piste comme inviolable de manière détectable à la portée de l’application, et associez-la aux contrôles de sauvegarde et d’accès base de données que vous appliquez déjà à vos autres systèmes de référence.

Quand un auditeur demande qui a approuvé un modèle et quand, la réponse est consignée : auteur, relecteur, approbateur, horodatage et empreinte d’export de ce qui a été publié.

Chaque réponse porte des en-têtes de sécurité navigateur modernes — Content-Security-Policy, HTTP Strict Transport Security, protections contre le clickjacking et le MIME-sniffing, et une Permissions-Policy verrouillée. La limitation de débit protège l’authentification et les autres points d’entrée sensibles, et les contrôles de dépendances et de sécurité s’exécutent en intégration continue.

Contrôle de publication

Une version n’est publiée que si son contrôle de publication est passé : la configuration de production démarre à froid sur des volumes vides et passe un smoke test, chaque image de conteneur est analysée avec Trivy — une vulnérabilité HIGH ou CRITICAL pour laquelle un correctif existe arrête la publication —, et l’application en fonctionnement est attaquée de l’extérieur avec OWASP ZAP, une découverte grave arrêtant également la publication. Les images livrées sont celles qui ont été testées ; elles ne sont pas reconstruites ensuite.

Nomenclature logicielle (SBOM)

Chaque version comprend une SBOM CycloneDX par image, plus une pour l’ensemble du graphe de dépendances, afin que vous puissiez confronter ce qui vous est livré à vos propres sources de vulnérabilités.

Rythme des versions et support

Les versions portent le mois de leur publication, par exemple 2026.11, et paraissent environ une fois par trimestre. Chacune reçoit des correctifs pour les vulnérabilités élevées et critiques pendant neuf mois après sa publication. Les correctifs sortent lors d’une journée de correctifs mensuelle ; un correctif pour une vulnérabilité critique ne l’attend pas. Rien ne se met à jour tout seul : vous décidez quand une installation passe à une nouvelle version.

Vos données vous appartiennent

Vos contenus sont les vôtres. Ils sont exportables à tout moment ; à la fin du contrat, ils peuvent être exportés immédiatement et supprimés sur demande. En on-premise, vous pilotez la destruction directement.

RGPD

L’opérateur est établi dans l’UE (Mews Group SAS, France). En on-premise, vos données de processus restent dans votre propre infrastructure et votre propre juridiction — elles ne nous sont pas transmises, il n’y a donc aucun transfert hors UE à justifier de notre côté.

Aucun traçage tiers

Aucun partage de données personnelles avec des tiers, aucun cookie tiers, et aucun accès aux contacts, à l’agenda ou à d’autres données de l’appareil.

L’IA est une couche d’assistance optionnelle : elle propose, un humain approuve. Par défaut, le contenu de vos prompts n’est pas stocké ; si un administrateur active l’historique du chat, celui-ci reste dans votre propre base de données. Voir Gouvernance de l’IA pour le fonctionnement des clés fournisseur, de la conservation des données et de l’inférence privée ou auto-hébergée.

Nous évaluons nous-mêmes OpsCodex au regard de l’OWASP Application Security Verification Standard (ASVS) 5.0.0, au niveau 2. Le niveau 2 inclut le niveau 1 : les 253 exigences des deux niveaux sont donc évaluées une par une, au regard du code source, des tests, des images de conteneurs et des artefacts de déploiement de la version. Chaque exigence satisfaite indique l’endroit du code, du test ou de la configuration qui l’impose ; chaque exigence non satisfaite indique le point ouvert qui la comblera.

Ce qu’elle n’est pas. Il s’agit de l’évaluation en boîte blanche que l’éditeur réalise lui-même, avec une revue de code assistée par IA puis vérifiée à la main. Ce n’est ni un test d’intrusion indépendant ni une certification. Elle est renouvelée à chaque version fonctionnelle et décrit donc la version que vous installez.

Évaluée le 29 octobre 2026, pour la version 2026.11.

Résultat par niveau

Niveau	Exi­gences	Satis­faite	En partie	Non satis­faite	N/A
Niveau 1, le socle	70	42	23	0	5
Niveau 2, niveau 1 compris	253	92	88	11	62

Satisfaite vaut pour chaque partie concernée d’OpsCodex ; En partie pour certaines d’entre elles ; N/A signifie que l’objet de l’exigence n’existe pas dans OpsCodex (par exemple WebRTC, ou un serveur d’autorisation OAuth). Certaines exigences dépendent de l’installation (par exemple TLS en bordure de votre réseau, ou la connexion multifacteur auprès de votre fournisseur d’identité) ; elles sont jugées d’après ce qu’OpsCodex livre et documente, jamais comptées comme N/A.

En partie signifie le plus souvent l’une de deux choses : le code satisfait l’exigence, mais l’ASVS demande aussi un document qui n’existe pas encore ; ou l’exigence est satisfaite presque partout, mais pas encore à un endroit.

20 points sont encore ouverts, aucun de priorité élevée. Chacun est suivi chez nous comme une tâche.

L’évaluation complète — une ligne par exigence, avec les preuves et le détail de chaque manque — est mise à la disposition de votre équipe sécurité sous accord de confidentialité (NDA) : [email protected].

Une page sécurité qui n’énumère que ce qui existe ne vous dit que la moitié de ce dont vous avez besoin. Voici les manques que vous devriez sinon découvrir en posant des questions — nommés ici pour que vous puissiez les peser tôt plutôt que tard.

Certifications

Ni ISO 27001, ni SOC 2, ni TISAX. OpsCodex fonctionne on-premise dans votre propre environnement certifié, c’est pourquoi ce n’a pas été un obstacle jusqu’ici. Si un certificat est obligatoire dans votre processus d’achat, parlez-en tôt.

Test d’intrusion indépendant

Aucun commandité à ce jour. OpsCodex fonctionne on-premise, dans votre propre périmètre, et non comme un service exposé sur Internet. Votre équipe sécurité, ou le prestataire avec lequel vous travaillez déjà, peut donc tester exactement l’installation que vous exploitez, et nous accompagnons ce test directement. De notre côté : une analyse quotidienne de toutes les dépendances et des images de base sur lesquelles reposent les versions, une analyse statique hebdomadaire du code, l’analyse des conteneurs et une attaque automatisée de l’extérieur sur l’application en fonctionnement à chaque contrôle de publication, et un test de non-régression qui fait échouer la compilation si les en-têtes de sécurité ci-dessus disparaissent. L’auto-évaluation ASVS ci-dessus est la nôtre et ne remplace pas un test indépendant.

Classification des données et étiquettes DLP

Aucune fonction d’étiquetage de sensibilité ni de DLP. L’accès est contrôlé structurellement : rôles, permissions par équipe, et une frontière stricte entre brouillons internes et portail publié.

Service de gestion de clés

Chaque secret réside dans votre propre environnement et nous n’en détenons aucun — mais il n’existe aucune intégration à un KMS ou HSM managé, si votre organisation préfère conserver ses clés ainsi.

Si vous trouvez un manque que ni cette liste ni les points ouverts de l’auto-évaluation ASVS ne nomment, dites-le-nous : il y sera ajouté. Une page comme celle-ci ne vaut d’être lue que si elle est complète.

Vous avez trouvé une faille de sécurité ? Merci d’écrire à [email protected].