Sécurité et méthode
Ce que nous faisons n'est pas possible sans confiance.
Nous opérons dans vos systèmes, avec vos données, pour le compte de vos clients. Notre protocole de sécurité est non négociable et documenté avant chaque mission.
Notre engagement
Autorisation écrite avant tout
Nous ne commençons à travailler sur aucun système sans un périmètre d'accès signé. Ce document nomme les systèmes autorisés, les comptes utilisés, les rôles assignés et les limites absolues. Il est révisé à chaque extension de périmètre.
Least privilege — accès minimum requis
Chaque agent n'a accès qu'aux ressources strictement nécessaires à sa tâche. Un agent de lecture email n'a pas accès au CRM. Un agent de mise à jour CRM n'a pas accès aux emails. Les permissions sont documentées et auditables.
Dry-run obligatoire avant toute mutation
Avant d'exécuter toute action qui modifie des données, l'agent s'exécute en mode simulation. Vous voyez exactement ce qui serait fait, sans que rien ne se passe réellement. La production ne démarre qu'après votre validation explicite.
Logs d'audit consultables par le client
Chaque action exécutée — lecture, écriture, envoi, refus — est enregistrée avec un horodatage, l'identité de l'agent, le résultat et les données concernées. Ces logs vous appartiennent et restent dans votre infrastructure.
Plan de rollback défini à l'avance
Avant toute mise en production, nous définissons avec vous un plan de retour arrière: que se passe-t-il si l'automatisation produit un résultat inattendu? Qui est notifié? Comment revenir à l'état précédent? Ce plan est testé avant le démarrage.
Exemple de log d'audit
Chaque action est horodatée, identifiée par agent, et indique le statut. Les entrées "pending" sont en attente d'approbation humaine.
| Timestamp (UTC) | Agent | Action | Statut |
|---|---|---|---|
| 2026-05-19T08:14:33Z | lead-qualifier | READ email:inbox#1821 | ok |
| 2026-05-19T08:14:35Z | lead-qualifier | WRITE crm:contact#NEW pending approval | pending |
| 2026-05-19T08:15:01Z | lead-qualifier | WRITE crm:contact#4482 — approved by M.D. | ok |
| 2026-05-19T08:22:47Z | email-triage | WRITE drafts:reply#928 — awaiting approval | pending |
Ce que nous ne faisons jamais
Données et résidence
Vos données restent dans vos systèmes. Nous ne maintenons aucune base de données centrale et n'exportons rien sans accord signé.
-
Aucune donnée client n'est copiée vers des services tiers sans accord explicite et écrit.
-
Les credentials sont stockés via un gestionnaire de secrets approuvé — jamais en clair dans le code, les notes ou les prompts.
-
Les données sensibles (données personnelles, financières) ne sont pas journalisées sauf nécessité fonctionnelle explicitement validée.
-
Les données restent dans vos systèmes. Nous n'opérons pas de base de données centrale côté agence.
Modèles utilisés et résidence
Nous choisissons le modèle selon la sensibilité des données traitées — pas selon une logique uniforme.
-
Pour les données personnelles de locataires et propriétaires : LLM hébergés en Suisse ou dans l'UE, ou en local selon le périmètre contractualisé.
-
Aucune donnée client n'est utilisée pour entraîner des modèles, en aucun cas.
-
Le routing exact, les fournisseurs utilisés et les zones de traitement sont documentés et signés avant tout démarrage.
-
Si votre cas exige une résidence stricte Suisse, nous opérons via des modèles compatibles (Apertus ou hébergement Exoscale-classe).
Sortie et portabilité
Pas de boîte noire. Pas de format propriétaire. Si vous décidez d'arrêter, vous repartez avec tout ce qu'il faut pour continuer sans nous.
-
Spécification fonctionnelle, diagrammes de flux, prompts et code livrés en clair.
-
Tous les artefacts vous appartiennent par contrat dès la livraison.
-
Une équipe IT interne ou un autre prestataire peut reprendre les workflows à partir de la documentation fournie.
-
Le périmètre d'accès aux systèmes est révocable à tout moment, sans pénalité.
Des questions sur notre protocole?
Parlons-en directement. Aucune préparation requise de votre côté.
Nous contacter