Sécurité des données sur Archyl Cloud : ce que nous protégeons, comment, et ce que nous ne prétendons pas

Quelque part dans votre questionnaire fournisseur, une ligne demande : « Les données client sont-elles chiffrées au repos ? Oui / Non ». Pour Archyl Cloud, la réponse exacte est « oui, et voici précisément quels champs ». Le texte de votre architecture (noms, descriptions, ADR, documentation) et vos identifiants d'accès sont chiffrés par notre application avant même que la base de données ne les voie. Les fichiers téléversés sont chiffrés par le fournisseur de stockage. Les identifiants techniques (ID), les horodatages, les positions dans les diagrammes et les e-mails des comptes restent en clair, parce que la base de données doit pouvoir les indexer et les joindre. Un fournisseur qui coche « Oui » sans préciser ce qui relève de quoi vous demande de croire le reste du questionnaire sur parole.

Cet article est la réponse longue. Il couvre ce que nous chiffrons et comment, la façon dont les données circulent, qui peut accéder à quoi, ce que reçoit notre fournisseur d'IA, notre manière de tester, et ce que vous pouvez faire au titre du RGPD. Il dit aussi clairement où nous n'en sommes pas encore : Archyl ne détient aujourd'hui aucune certification de sécurité.

Tout ce qui figure ici est cohérent avec le livre blanc sécurité (v3.0) et l'accord de traitement des données (DPA), tous deux mis à jour le 27 septembre 2026 et tous deux accessibles depuis le Centre de confiance. Si une phrase d'ici et une phrase de là-bas se contredisent un jour, dites-le-nous, car l'une des deux est fausse.

La version courte

Pour ceux qui remplissent un formulaire en ce moment même :

Le reste de l'article détaille chacune de ces lignes.

Le chiffrement au repos, champ par champ

Archyl chiffre les champs dans l'application, avant qu'ils ne soient écrits en base de données. Chaque modèle qui contient du contenu client porte un hook d'enregistrement qui chiffre ses champs texte en AES-256-GCM à l'entrée, et un hook correspondant qui les déchiffre à la sortie. Chaque chiffrement utilise un nonce aléatoire neuf, si bien que la même valeur stockée deux fois produit deux textes chiffrés différents.

Cela couvre votre contenu d'architecture, pas seulement vos secrets :

• Modèle C4 : systèmes, containers, components et éléments de code (nom, description, tags) ; relations (description, tags)
• Architecture Decision Records : titre, contexte, décision, conséquences, tags
• Documentation : titre, contenu, chemin de fichier, tags ; les commentaires associés
• Contrats d'API : nom, description, contenu, endpoint, version
• Flows et whiteboards : noms, descriptions, libellés de technologie
• Également : overlays, canaux d'événements, insights, releases, règles de conformité, historique des modifications et snapshots

Ainsi que chaque identifiant d'accès et chaque secret stocké par Archyl :

• Tokens OAuth de GitHub, GitLab et Bitbucket
• Clés d'API
• Secrets MFA et codes de récupération
• Identifiants d'accès des intégrations et de la marketplace
• Tokens d'accès aux dépôts
• Paramètres de connexion cloud

Ce chiffrement est toujours actif. La clé de chiffrement est dérivée avec Argon2id à partir d'un secret configuré, et le serveur s'arrête au démarrage si ce secret est absent ou fait moins de 32 caractères. Il n'existe aucune configuration dans laquelle Archyl tourne et écrit ces champs en clair.

La conséquence pratique : une copie de la base de données, à elle seule, montre la forme de vos données mais pas leurs mots. Les noms de vos services, le raisonnement de vos ADR, le corps de vos docs, votre token GitHub et votre secret MFA nécessitent tous, en plus, la clé.

Les identifiants d'accès ne ressortent jamais non plus par l'API. Les paramètres d'intégration sont masqués à chaque lecture : une fois que vous avez collé une clé dans Archyl, l'interface peut vous indiquer qu'une clé est stockée, mais ne peut pas vous la réafficher, et aucun appel d'API ne la renvoie à qui que ce soit d'autre dans votre organisation.

Ce que cela ne couvre pas

Une base de données doit pouvoir retrouver, trier et joindre des lignes, et elle ne peut pas le faire sur du texte chiffré. Certains champs restent donc en clair :

• Les identifiants techniques et les liens entre éléments. La base de données sait que l'élément A appartient au container B et a une relation avec l'élément C. Elle ne sait pas comment aucun d'eux s'appelle.
• Les horodatages et les positions dans les diagrammes.
• Les adresses e-mail, prénoms et noms des comptes. L'e-mail porte un index unique, afin que deux comptes ne puissent pas revendiquer la même adresse.

Ces champs sont protégés par les contrôles d'accès décrits plus bas et par TLS en transit. Cet article n'affirme rien, ni dans un sens ni dans l'autre, sur le chiffrement au niveau disque de la base de données.

Fichiers téléversés

Les fichiers que vous joignez à la documentation (images, PDF, autres documents) ne résident pas dans la base de données. Ils sont stockés dans Google Cloud Storage, et :

• Les buckets sont privés. Rien de ce qu'ils contiennent n'est lisible ni listable publiquement.
• Les fichiers sont chiffrés au repos en AES-256 par Google Cloud Storage, avec des clés gérées par le fournisseur.
• Les fichiers ne sont servis que via des URL signées de courte durée. Chaque lien donne accès à un seul fichier et expire peu après sa génération : un lien copié dans un ticket ou une conversation cesse de fonctionner au lieu de devenir une URL publique permanente.
• La région par défaut est l'UE : Belgique, europe-west1.

Le chiffrement en transit

Le trafic entre votre navigateur, vos outils et Archyl Cloud utilise TLS 1.3. La connexion de l'application à sa base de données PostgreSQL exige SSL : l'application ne communique donc pas en clair avec la base de données.

Qui peut entrer

Les personnes

• L'authentification multifacteur utilise TOTP, les codes à six chiffres d'une application d'authentification. Chaque challenge MFA n'est utilisable qu'une fois, et les codes de récupération sont stockés sous forme de hachages bcrypt : ils peuvent être vérifiés mais pas relus.
• Le single sign-on prend en charge SAML 2.0 et OpenID Connect. La connexion démarre toujours chez Archyl (uniquement SP-initiated), et l'état qui relie la réponse de votre fournisseur d'identité à cette requête est lié au navigateur qui l'a initiée et n'est valable qu'une fois. Notre article sur le SSO couvre la mise en place.
• La connexion OAuth est disponible avec GitHub, GitLab et Bitbucket.
• Changer de mot de passe ou retirer la MFA révoque toutes les sessions plus anciennes. Si vous pensez qu'un mot de passe a fuité, le changer déconnecte tous les autres appareils qui l'utilisaient.
• La réinitialisation du mot de passe ne révèle pas si un compte existe, et un lien de réinitialisation cesse de fonctionner une fois utilisé.
• La connexion, la MFA et la réinitialisation du mot de passe sont soumises à un rate limiting, avec des limites superposées afin qu'une même IP, un même compte ou un même challenge ne puisse chacun être tenté qu'un nombre limité de fois.

Les machines : clés d'API et agents IA

• Les clés d'API sont en lecture seule par défaut. L'accès en écriture doit être accordé, et une clé peut être restreinte à des projets précis : une clé confiée à un job de CI qui ne fait que lire le modèle d'un projet peut faire exactement cela.
• Le serveur MCP, que les agents IA utilisent pour lire et mettre à jour votre architecture, s'authentifie via OAuth avec PKCE obligatoire. Chaque mutation exige un scope d'écriture : un agent que vous avez connecté pour répondre à des questions sur votre architecture ne peut pas la modifier, sauf si vous lui avez accordé l'accès en écriture.

Isolation des tenants

La défaillance contre laquelle tout produit multi-tenant doit se prémunir est simple à décrire : le serveur vérifie que vous êtes connecté et que vous appartenez à une organisation, puis fait confiance à n'importe quel identifiant présent dans la requête. Changez l'ID dans l'URL, et vous lisez les données de quelqu'un d'autre.

Archyl autorise chaque requête par rapport à la ressource qu'elle touche. Demander un diagramme, un document ou une clé implique de vérifier que le projet ou l'organisation propriétaire de cette ressource précise en est un auquel vous avez accès, et pas seulement que vous êtes connecté. La même règle s'applique à l'API HTTP et au serveur MCP.

Deux propriétés garantissent que cela tient dans la durée :

• L'autorisation échoue en position fermée (fail closed). Si la propriété d'une ressource ne peut pas être déterminée, la réponse est non.
• Des tests automatisés de tenancy s'exécutent en CI et font échouer le build si un contrôle d'autorisation est supprimé, plutôt que d'attendre que quelqu'un s'en aperçoive.

Ce que voit l'IA

Les fonctionnalités d'IA d'Archyl Cloud utilisent OpenAI, et aucun autre fournisseur d'IA, sauf si votre organisation configure sa propre clé.

Pour la découverte d'architecture, qui lit un dépôt et propose un modèle C4, nous envoyons des signatures de code plutôt que du code source. Voici un fichier tel qu'il se trouve dans votre dépôt :

package billing

import (
	"context"
	"github.com/stripe/stripe-go/v82"
)

type InvoiceService struct {
	Repo InvoiceRepository
}

func (s *InvoiceService) Finalize(ctx context.Context, id string) error {
	inv, err := s.Repo.Get(ctx, id)
	if err != nil {
		return err
	}
	if inv.Total > approvalThreshold {
		return ErrNeedsApproval
	}
	return s.Repo.MarkFinal(ctx, id)
}

Et voici la section que la découverte construit à partir de celui-ci, c'est-à-dire ce qui entre dans le prompt :

--- internal/billing/service.go [go] ---
Imports: context, github.com/stripe/stripe-go/v82
Types: struct InvoiceService,   InvoiceService.Repo InvoiceRepository
Functions: func (s *InvoiceService) Finalize(ctx context.Context, id string) error

La règle d'approbation, le seuil et le corps de Finalize restent à l'écart. Ce qui y entre : le nom du dépôt, la structure des fichiers et des répertoires, et ces signatures (imports, déclarations de types et de fonctions, constantes exportées). Cela suffit pour comprendre qu'un component de facturation communique avec Stripe. Ce n'est pas rien pour autant : les noms de fonctions et de types décrivent votre système, alors traitez-les comme des données que vous partagez.

Deux limites à cette affirmation, pour que vous n'y lisiez pas plus qu'elle ne dit :

• Elle décrit le traitement du code source par la découverte. Si la découverte trouve dans le dépôt des Architecture Decision Records rédigés en Markdown, elle envoie leur texte afin de les transformer en décisions structurées, et elle envoie les premières lignes des fichiers de documentation pour leur donner un titre.
• Les autres fonctionnalités d'IA envoient ce dont leur tâche a besoin. Un agent de code, par exemple, travaille sur les fichiers qu'il modifie : il les voit donc.

Si votre politique impose que le code ne soit envoyé qu'à un fournisseur avec lequel vous avez un contrat, les organisations peuvent apporter leur propre clé d'IA. Les requêtes d'IA partent alors vers ce fournisseur, sous votre contrat. Si rien ne doit quitter votre réseau, un Archyl auto-hébergé peut faire tourner des modèles avec Ollama sur votre propre matériel.

Comment nous le testons

Dans le pipeline

Notre pipeline de CI exécute quatre scanners de sécurité :

• govulncheck pour les vulnérabilités connues dans les dépendances Go que nous appelons réellement
• CodeQL pour l'analyse statique de notre propre code
• gitleaks pour les secrets commités par erreur
• Trivy pour les vulnérabilités dans les images de containers et la configuration d'infrastructure

Dans la plateforme

• Les requêtes sortantes sont contrôlées. Chaque intégration qui appelle une URL que vous fournissez (un serveur Git auto-hébergé, un webhook, un endpoint d'IA) est protégée contre la server-side request forgery (SSRF), afin que cette URL ne puisse pas servir à faire atteindre à Archyl son propre réseau interne.
• Le navigateur n'exécute que les scripts que nous livrons. Une Content-Security-Policy stricte liste chaque script inline par son hash, et les scripts chargés depuis un CDN portent des hashes Subresource Integrity : une copie modifiée est refusée.
• Les containers sont verrouillés. Ils tournent sous un utilisateur non root, sur un système de fichiers en lecture seule, avec les capabilities Linux retirées.
• Les événements de sécurité sont journalisés, notamment les échecs de connexion, les tentatives MFA échouées et les tokens rejetés.

Tests d'intrusion

Entre juillet et septembre 2026, nous avons mené dix campagnes de tests d'intrusion internes. Chaque constat a été corrigé et couvert par un test de régression, de sorte que le même problème soit détecté s'il réapparaît.

« Interne » signifie exactement cela : nous avons mené ces tests nous-mêmes, et aucune société indépendante n'y a participé. Un test d'intrusion indépendant est prévu dans le cadre de l'audit SOC 2.

Vos droits au titre du RGPD

• Export. Vous pouvez exporter vos données au format JSON.
• Suppression. Supprimer votre compte supprime tout ce qui lui appartient, en cascade à travers vos données, y compris les pièces jointes téléversées dans le stockage objet.
• Un DPA pour chaque client. L'accord de traitement des données est disponible pour tous les clients.
• Notification de violation de données sous 72 heures.
• Un préavis de 30 jours avant tout changement de nos sous-traitants, afin que vous puissiez vous y opposer avant que le changement n'ait lieu.

Voici nos sous-traitants aujourd'hui :

Le DPA indique la localisation et les garanties juridiques de chacun.

Ce que nous ne prétendons pas encore

Une page sécurité qui ne liste que des points forts vous laisse trouver les lacunes vous-même. Les voici :

• Aucune certification. Archyl n'est pas certifié SOC 2 et n'est pas certifié ISO 27001. Pour SOC 2 Type I, l'évaluation de préparation (readiness assessment) est terminée et l'audit indépendant est en attente. ISO 27001 est prévu. Lorsqu'un rapport d'audit existera, le Centre de confiance le dira ; d'ici là, rien de ce que nous publions ne devrait laisser entendre le contraire.
• Pas encore de test d'intrusion indépendant. Les dix campagnes décrites plus haut étaient internes. Le test indépendant viendra avec l'audit SOC 2.
• Toutes les colonnes ne sont pas chiffrées. Les identifiants techniques, les horodatages, les positions dans les diagrammes, les e-mails et les noms restent en clair, comme décrit plus haut.

Si votre processus exige une certification qu'Archyl n'a pas encore, c'est une contrainte réelle, et nous préférons que vous le sachiez maintenant plutôt qu'à la sixième semaine d'une revue d'achat.

Pour aller plus loin

• Le Centre de confiance rassemble les documents en un seul endroit.
• Le livre blanc sécurité approfondit chaque contrôle, y compris les limites de débit et les événements de sécurité que nous journalisons.
• L'accord de traitement des données est la version contractuelle de la section RGPD ci-dessus.
• Pour les questions de protection des données, ou les points de questionnaire auxquels cet article ne répond pas, écrivez à privacy@archyl.com.
• Pour signaler une vulnérabilité, écrivez à security@archyl.com. Nous accusons réception sous 24 heures.

Si c'est vous qui devez donner le feu vert à Archyl, nous préférons que vous trouviez une réponse précise à chaque question plutôt qu'une réponse assurée à la plupart d'entre elles. Là où quelque chose ici n'est pas assez précis pour votre revue, demandez-le-nous, et nous le rendrons précis.