calmaria
Comment ça marcheNotre scan gratuit
← Retour à Calmaria

Cas clients

Construit vite avec des agents.
Rendu robuste ensuite.

Quatre équipes ont livré vite avec des agents : code, infrastructure, accès aux données, agents en production. Voici ce qu’elles avaient construit, ce que nous avons trouvé, ce que nous avons changé, et ce qui reste de leur ressort. Le cas santé concerne un hébergement de données de santé mis en place pour la Société Française de Cardiologie, scanné régulièrement par nos agents ainsi que par un prestataire d’hébergement.

Cas 01Finance régulée · capital-investissement

Successions de souscripteurs : des agents d’instruction, un registre à protéger.

Société de gestion de portefeuille agréée par l’AMF, 40 collaborateurs, six FPCI et deux FCPR.

Illustration du cas client : un tentacule indigo présente un feuillet menthe devant un registre lavande et deux blocs.
Illustration abstraite du cas client ; elle ne représente pas son infrastructure.

Le contexte

Le décès d’un souscripteur ouvre l’instruction de la transmission de ses parts. L’équipe recueille les pièces demandées par le teneur de registre et le notaire, notamment la preuve du décès et de la qualité d’héritier. Elle vérifie la dévolution, les éventuelles options successorales, l’indivision ou le démembrement, puis applique les diligences de connaissance client et de vigilance requises selon les personnes concernées et les risques. Les inscriptions et les modalités de versement des distributions sont validées suivant le règlement du fonds, les justificatifs et les instructions autorisées. Le teneur de registre, le dépositaire et la société de gestion interviennent selon leurs missions contractuelles respectives.

Ce que l’équipe avait construit avec des agents

En quelques mois, l’équipe a construit avec des agents de code une chaîne d’instruction : un agent lit les pièces notariales et en extrait la dévolution, un deuxième lance les contrôles de vigilance, un troisième rédige les courriers et prépare les écritures du registre ainsi que la reprise des distributions.

  • 0écriture au registre sans double validation, sur six mois
  • 19 → 7 jdélai moyen d’instruction d’une succession, en jours ouvrés
  • 14/14pièces piégées de test arrêtées avant toute écriture

Avantl’agent écrit seul

Avant : l’agent écrit seulLes pièces notariales reçues en PDF alimentent les agents d’instruction, qui écrivent seuls dans le registre des porteurs et déclenchent seuls le virement de distribution. Le gestionnaire valide un résumé, pas l’action exécutée.écrit seulvire seulPièces notariales (PDF)Agents d’instructionRegistredes porteursVirementde distributionLe gestionnaire valide un résumé,pas l’action exécutée.

Aprèsl’agent prépare, deux gestionnaires valident le registre

Après : l’agent prépare, deux gestionnaires valident le registreLes pièces sont traitées comme des données. Les agents lisent et préparent. Deux gestionnaires distincts valident chaque modification du registre. Les paiements suivent les délégations et contrôles définis pour les distributions. Le journal relie pièce, version de l’agent, contrôles, valideurs et opération exécutée.Pièces traitées comme donnéesAgents : lecture et préparationGestionnaire :action exacteSecond valideurchaque écritureOutil métier : registre, virementau nom du gestionnaireJournal horodaté : pièce, version,contrôle, valideur, écriture.
Schéma du cas client : flux et droits avant, puis après notre intervention.

  1. Ce que nous avons trouvéInjection de consignes via un PDF reçu : une consigne cachée dans une pièce pouvait modifier la répartition proposée entre héritiers.

    Ce que nous avons changéLes pièces sont traitées comme des données, jamais comme des instructions : extraction structurée, rapprochement avec l’acte de notoriété, alerte sur tout contenu inattendu.

  2. Ce que nous avons trouvéL’agent de préparation disposait d’un compte de service capable d’écrire dans le registre et de déclencher un virement de distribution.

    Ce que nous avons changéDroits de l’agent ramenés à la lecture et à la préparation. L’écriture et le virement passent par l’outil métier, sous l’identité d’un gestionnaire.

  3. Ce que nous avons trouvéLe gestionnaire validait un résumé, pas l’action réellement exécutée : le principe des quatre yeux n’était pas appliqué.

    Ce que nous avons changéToute modification du registre est validée par deux gestionnaires distincts sur l’action exacte. Pour les distributions, le montant, l’IBAN et le bénéficiaire sont affichés avant validation ; les délégations et contrôles de paiement sont définis séparément.

  4. Ce que nous avons trouvéIdentités, coordonnées bancaires et pièces d’état civil des héritiers copiées dans les journaux du modèle et un espace partagé.

    Ce que nous avons changéDonnées minimisées et masquées dans les journaux, durée de conservation fixée, espace partagé purgé.

  5. Ce que nous avons trouvéClé d’API du teneur de registre écrite en clair dans la configuration d’un agent.

    Ce que nous avons changéClé révoquée et remplacée, secrets placés dans un coffre, accès nominatifs.

  6. Ce que nous avons trouvéJournaux inexploitables pour un contrôle de l’AMF : impossible de relier une écriture à sa pièce source et à son valideur.

    Ce que nous avons changéJournal horodaté et conservé : pièce source, version de l’agent, contrôle effectué, valideur, écriture produite.

  7. Ce que nous avons trouvéFournisseur de modèle et outil de lecture des documents absents du registre des prestataires TIC.

    Ce que nous avons changéFiches prestataires préparées pour le registre d’informations prévu par DORA et pour la revue des contrats.

Ce qui reste de la responsabilité du client

  • La décision sur chaque succession, la validation des pièces notariales et la qualification des ayants droit.
  • Le dispositif LCB-FT : déclarations de soupçon, mesures de gel et décisions de vigilance restent celles de la société de gestion.
  • Les relations avec le dépositaire, le teneur de registre et les notaires.
  • La conformité de l’ensemble : notre examen est technique. Il ne vaut ni avis juridique ni attestation de conformité. Les tests d’intrusion relèvent d’un prestataire indépendant.

Cadre réglementaire

  • DORA

    DORA vise les gestionnaires de fonds d’investissement alternatifs (art. 2, § 1, k), sous réserve des exclusions de son article 2, § 3. Pour une société entrant dans son champ : gestion du risque lié aux TIC (art. 5 à 16), registre d’informations et risques liés aux prestataires tiers de services TIC (art. 28 à 30). L’assujettissement du gestionnaire doit être confirmé.

    Règlement (UE) 2022/2554

  • LCB-FT

    Obligations de vigilance à l’égard de la clientèle et de ses bénéficiaires effectifs ; mesures complémentaires pour les personnes politiquement exposées (art. L561-10).

    Code monétaire et financier, art. L561-1 et suivants

  • Gel des avoirs

    Application sans délai des mesures de gel et interdiction de mise à disposition des fonds (art. L562-4 et L562-4-1).

    Code monétaire et financier, art. L562-1 à L562-15

  • RGPD

    Protection des données dès la conception (art. 25) et sécurité du traitement (art. 32), pour les données des héritiers.

    Règlement (UE) 2016/679

« Nos agents faisaient gagner des semaines. Il manquait la preuve que personne, ni humain ni agent, ne pouvait écrire seul dans le registre. »

Responsable de la conformité et du contrôle interne · Société de gestion de portefeuille
Cas 02Santé

Des données de santé hébergées, et surveillées dans la durée.

Société Française de Cardiologie (SFC), société savante.

Illustration abstraite : des cartes menthe abritées sous un pavillon lavande, éclairé de blanc et de menthe, à côté d’un tentacule indigo.
Illustration abstraite de l’hébergement ; elle ne représente pas l’infrastructure de la SFC.

Le fait établi

Nous avons mis en place un hébergement de données de santé pour la Société Française de Cardiologie. Il est scanné régulièrement par nos agents ainsi que par un prestataire d’hébergement.

Ce que l’équipe avait construit avec des agents

Les applications reliées à l’hébergement évoluent avec l’aide d’agents de code. Chaque livraison peut modifier une règle d’accès ou une configuration : c’est ce que les scans réguliers vont chercher.

  • 2regards réguliers sur l’hébergement : nos agents et le prestataire d’hébergement
  • 52scans par an de nos agents
  • 24 hdélai maximal entre une livraison et son scan par nos agents

Mise en placeUn hébergement de données de santé

Un hébergement de données de santéCalmaria met en place un hébergement de données de santé pour la Société Française de Cardiologie.met en placepourCalmariaHébergement dedonnées de santéSociété Françaisede Cardiologie

SurveillanceDeux regards réguliers, dans la durée

Deux regards réguliers, dans la duréeL’hébergement de données de santé est scanné régulièrement par les agents de Calmaria ainsi que par un prestataire d’hébergement.Nos agentsPrestataired’hébergementHébergement dedonnées de santéscansréguliers
Schéma de l’hébergement mis en place, puis scanné régulièrement par nos agents et par un prestataire d’hébergement.

  1. Le besoin ou le constatDes données de santé à héberger.

    L’interventionMise en place d’un hébergement de données de santé.

  2. Le besoin ou le constatUn hébergement à surveiller dans la durée.

    L’interventionScans réguliers par nos agents, ainsi que par un prestataire d’hébergement.

  3. Le besoin ou le constatChaque livraison des applications reliées peut modifier une règle d’accès ou une configuration.

    L’interventionUn scan de nos agents après chaque livraison, en plus du rythme régulier.

  4. Le besoin ou le constatDes accès d’administration à maintenir au plus juste dans la durée.

    L’interventionRevue périodique des comptes et des droits d’accès avec l’équipe.

Ce qui reste de la responsabilité du client

  • Le statut de chaque hébergeur se vérifie auprès de lui : cette page n’affirme aucune certification, ni pour nous ni pour un tiers.
  • Les finalités, les bases légales et l’information des personnes relèvent du responsable de traitement.
  • Nos scans ne remplacent ni l’audit de certification d’un hébergeur, ni un test d’intrusion, qui relève d’un prestataire indépendant.
  • Aucun scan ne garantit l’absence de faille.

Cadre réglementaire

  • Hébergement de données de santé

    Pour les données de santé à caractère personnel recueillies à l’occasion d’activités de prévention, de diagnostic, de soins ou de suivi social et médico-social, l’article L1111-8 encadre l’hébergement pour le compte de leur producteur, de leur collecteur ou du patient. Sur support numérique, la certification d’hébergeur de données de santé s’apprécie selon les activités d’hébergement exercées et les rôles contractuels. Cette page n’atteste le statut HDS d’aucun intervenant.

    Code de la santé publique, art. L1111-8

  • Référentiel HDS

    Exigences de la certification des hébergeurs de données de santé et liste des organismes certificateurs.

    Agence du numérique en santé

  • RGPD

    Données concernant la santé, catégorie particulière (art. 9) ; sous-traitance encadrée par contrat (art. 28) ; sécurité du traitement (art. 32).

    Règlement (UE) 2016/679
Cas 03Éditeur SaaS B2B

Un produit écrit avec des agents, à l’épreuve d’une levée et d’un grand compte.

Éditeur SaaS de gestion des achats, 45 personnes, série A en préparation ; prospect : un groupe bancaire.

Illustration du cas client : un tentacule indigo place une cloison entre trois modules lavande à tiroirs menthe.
Illustration abstraite du cas client ; elle ne représente pas son infrastructure.

Le contexte

Le groupe bancaire envoie un questionnaire sécurité avant de signer. Les investisseurs de la série A demandent une revue technique. L’équipe doit répondre vite, et répondre juste.

Ce que l’équipe avait construit avec des agents

La majeure partie du produit a été écrite avec des agents de code : interface, API, migrations de base. Les revues portaient surtout sur le fonctionnel ; chaque fusion partait automatiquement en production.

  • 0 → 38tables protégées par un contrôle d’accès par ligne
  • 11secrets révoqués et remplacés, dont la clé de service
  • 12 jentre le scan et la clôture des constats critiques

Avantune clé de service dans le navigateur

Avant : une clé de service dans le navigateurLe navigateur du client A reçoit la clé de service de la base. La base n’a pas de contrôle d’accès par ligne : le client A peut lire les données du client B.clé de serviceNavigateur du client ABase de données sanscontrôle par ligneDonnéesdu client ADonnéesdu client BLe client A peut lireles commandes du client B.

Aprèsun accès par client, vérifié

Après : un accès par client, vérifiéLe navigateur du client A n’a qu’un jeton de session. Les appels privilégiés passent par une API côté serveur. La base applique une politique par client : le client A lit ses données, l’accès aux données du client B est refusé. Des tests d’isolation tournent à chaque livraison.jeton de sessionrefuséNavigateur du client AAPI côté serveurBase : politique par clientDonnéesdu client ADonnéesdu client BTests d’isolationà chaque livraison.
Schéma du cas client : flux et droits avant, puis après notre intervention.

  1. Ce que nous avons trouvéLa clé de service de la base était livrée au navigateur : elle contournait toutes les règles d’accès.

    Ce que nous avons changéClé retirée du code client, révoquée et remplacée ; les appels privilégiés passent par le serveur.

  2. Ce que nous avons trouvéAucun contrôle d’accès par ligne : un client connecté pouvait lire les commandes d’un autre en changeant un identifiant.

    Ce que nous avons changéPolitiques par client sur toutes les tables partagées, avec des tests d’isolation entre deux comptes à chaque livraison.

  3. Ce que nous avons trouvéUne préproduction ouverte sur Internet, alimentée par une copie de la production.

    Ce que nous avons changéPréproduction fermée derrière une authentification, données synthétiques.

  4. Ce que nous avons trouvéDes secrets dans l’historique Git : anciennes clés de paiement et d’envoi d’e-mails toujours valides.

    Ce que nous avons changéSecrets révoqués, historique nettoyé, détection automatique avant chaque fusion.

  5. Ce que nous avons trouvéDes dépendances vulnérables ou abandonnées, sans versions verrouillées.

    Ce que nous avons changéInventaire des dépendances, mises à jour, versions verrouillées et alertes.

  6. Ce que nous avons trouvéUn questionnaire du grand compte rempli de « oui » difficiles à prouver.

    Ce que nous avons changéRéponses documentées avec l’équipe, preuves à l’appui ; ce qui n’est pas encore en place est dit comme tel.

Ce qui reste de la responsabilité du client

  • Les réponses au questionnaire engagent l’éditeur : nous l’aidons à les documenter, nous ne les signons pas.
  • Chaque nouvelle livraison écrite avec des agents mérite le même examen.
  • Le test d’intrusion demandé par la banque relève d’un prestataire indépendant.
  • Ni certification, ni garantie d’absence de faille.

Cadre réglementaire

  • RGPD

    Sous-traitant de ses clients, l’éditeur présente des garanties suffisantes (art. 28) et assure la sécurité du traitement (art. 32) ; il notifie toute violation au responsable de traitement dans les meilleurs délais (art. 33, § 2).

    Règlement (UE) 2016/679

  • DORA

    La banque cliente encadre ses prestataires tiers de services TIC (art. 28 à 30) : c’est l’origine de nombreux questionnaires adressés aux éditeurs.

    Règlement (UE) 2022/2554

« Les agents nous ont fait gagner un an. La revue nous a évité de le perdre en un après-midi. »

CTO et cofondateur · Éditeur SaaS B2B
Cas 04Assurance

Un agent de gestion des sinistres branché sur l’outil de règlement.

Mutuelle d’assurance IARD, 700 collaborateurs, 120 000 déclarations de sinistre par an.

Illustration du cas client : un tentacule indigo retient une carte menthe devant deux portiques, près d’une coupelle de disques vierges.
Illustration abstraite du cas client ; elle ne représente pas son infrastructure.

Le contexte

Pour absorber les pics de déclarations après un épisode de grêle, l’équipe innovation voulait instruire plus vite les sinistres simples, sans recruter dans l’urgence.

Ce que l’équipe avait construit avec des agents

Écrit en quelques semaines avec des agents de code, l’agent lit les déclarations et leurs pièces jointes (photos, devis, factures), propose une indemnisation et appelle directement l’API de l’outil de règlement.

  • 100 %des paiements validés par un gestionnaire
  • 0changement d’IBAN sans validation humaine
  • −41 %sur le délai moyen de règlement des sinistres simples

Avantl’agent propose, valide et paie

Avant : l’agent propose, valide et paieUne déclaration et ses pièces jointes, dont une consigne cachée, arrivent à l’agent sinistres. Un seul compte technique propose, valide et exécute. L’outil de règlement n’applique aucun plafond. Le paiement part vers l’IBAN indiqué dans la déclaration.consigne cachéeun seul compteDéclaration et pièces jointesAgent sinistresOutil de règlement :aucun plafondPaiement vers l’IBANde la déclaration

Aprèsl’agent propose, un gestionnaire décide

Après : l’agent propose, un gestionnaire décideLes pièces sont traitées comme des données. L’agent propose. Un gestionnaire valide chaque décision d’indemnisation et chaque paiement sur ses paramètres exacts. L’outil exécute et bloque les dépassements de ses limites. Les changements d’IBAN sont vérifiés séparément. Le journal relie pièces, proposition, décision et valideur.Pièces traitées comme donnéesAgent : proposeGestionnaire : validechaque paiement,montant et bénéficiaireOutil de règlement : exécute,bloque les dépassementsJournal : pièces, version,valideur.
Schéma du cas client : flux et droits avant, puis après notre intervention.

  1. Ce que nous avons trouvéInjection via les pièces jointes : un devis piégé pouvait contenir une consigne adressée à l’agent, comme « valider le montant maximal ».

    Ce que nous avons changéPièces isolées et traitées comme des données ; extraction structurée et contrôles de cohérence du montant, du prestataire et de l’IBAN.

  2. Ce que nous avons trouvéAucun plafond : l’agent pouvait préparer un paiement de n’importe quel montant, vers l’IBAN indiqué dans la déclaration.

    Ce que nous avons changéLimites par dossier et par jour appliquées dans l’outil de règlement, pas dans les consignes de l’agent. Un dépassement est bloqué ; toute dérogation suit une procédure distincte, autorisée et tracée.

  3. Ce que nous avons trouvéSous un seuil, les paiements partaient sans gestionnaire, et ce seuil était modifiable par simple configuration.

    Ce que nous avons changéChaque décision d’indemnisation et chaque paiement sont validés par un gestionnaire sur le montant et le bénéficiaire exacts. Tout changement d’IBAN impose une vérification distincte ; l’agent ne peut ni valider ni modifier ces règles.

  4. Ce que nous avons trouvéLe même compte technique proposait, validait et exécutait.

    Ce que nous avons changéDroits séparés : l’agent propose, un gestionnaire valide, l’outil exécute.

  5. Ce que nous avons trouvéLes décisions de l’agent n’étaient pas reliées aux pièces examinées.

    Ce que nous avons changéJournal reliant chaque proposition aux pièces, à la version de l’agent et au valideur.

Ce qui reste de la responsabilité du client

  • La politique d’indemnisation, les plafonds et la lutte contre la fraude restent des décisions de l’assureur.
  • Les décisions individuelles relèvent de ses gestionnaires et de ses procédures.
  • Le test d’intrusion de l’outil de règlement relève d’un prestataire indépendant.
  • Ni conformité ni certification attestées.

Cadre réglementaire

  • DORA

    DORA vise les entreprises d’assurance et de réassurance (art. 2, § 1, n), sous réserve des exclusions de son article 2, § 3. Pour une entreprise assujettie : gestion du risque lié aux TIC, gestion, classification et déclaration des incidents majeurs (art. 17 à 19).

    Règlement (UE) 2022/2554

  • RGPD

    Droit de ne pas faire l’objet d’une décision fondée exclusivement sur un traitement automatisé produisant des effets juridiques ou similaires (art. 22) ; sécurité du traitement (art. 32).

    Règlement (UE) 2016/679

  • AI Act

    En assurance, l’annexe III vise l’évaluation des risques et la tarification en assurance vie et santé (point 5, c). Un agent de gestion des sinistres IARD n’y figure pas en tant que tel ; chaque usage se qualifie au cas par cas.

    Règlement (UE) 2024/1689

« L’agent instruit. Un gestionnaire décide. Et nous pouvons le prouver, dossier par dossier. »

Responsable du contrôle interne · Mutuelle d’assurance

Avant la prochaine livraison

Ce que vos agents ont construit
mérite le même examen.

Le premier scan est gratuit. Il ne vaut ni certification, ni attestation de conformité, ni garantie d’absence de faille. Les tests d’intrusion relèvent d’un prestataire indépendant.

Demander le scan gratuit