Guide de traitement des données.

1. Comment un appel traverse notre système

Lorsque quelqu'un appelle une entreprise utilisant notre réceptionniste IA, voici le parcours que suivent l'audio et les données. Rien n'est persisté sur notre serveur au-delà de l'état d'appel en direct ; le stockage permanent se produit à l'étape Airtable.

• Twilio reçoit l'appel, l'achemine via ses points de présence canadiens et diffuse l'audio via une connexion WebSocket chiffrée vers notre serveur.
• Agent vocal s'exécute sur notre VPS canadien. Il transcrit la voix de l'appelant, envoie la transcription à l'IA pour traitement et restitue la réponse de l'IA via Twilio.
• Claude AI (Anthropic) traite la conversation en temps réel. L'API d'Anthropic applique une politique de zéro rétention — les entrées ne sont pas stockées ni utilisées pour l'entraînement du modèle.
• Airtable stocke l'enregistrement de l'appel, le résumé de la transcription et les détails du rendez-vous après la fin de l'appel — le premier point où quoi que ce soit est persisté.

2. Chiffrement et sécurité

En transit

• Tout le trafic HTTP utilise TLS 1.2+ (TLS 1.3 préféré). Appliqué au niveau nginx avec HSTS et une suite de chiffrement moderne.
• Les flux audio Twilio utilisent des connexions WebSocket chiffrées.
• Les appels API vers Anthropic, Airtable et Stripe utilisent HTTPS chiffré TLS.

Au repos

• Airtable chiffre toutes les données stockées avec AES-256.
• Notre fichier de secrets (/opt/secrets/secrets.enc.yaml) est chiffré avec SOPS + age. Le texte en clair ne touche jamais le disque — le fichier est déchiffré en mémoire au démarrage du service.
• Les permissions de fichiers sont verrouillées (chmod 600). Les secrets ne sont jamais écrits dans les journaux, jamais passés en ligne de commande, jamais soumis au code.
• Redis (cache en mémoire) stocke l'état temporaire d'appel avec expiration automatique — rien ne persiste sur disque.
• La base de données PostgreSQL hébergeant les données des workflows utilise des identifiants par base de données, rotés via le même store SOPS.

Hébergement canadien

• L'infrastructure serveur principale est hébergée au Canada (fournisseur VPS : Hostinger, région canadienne).
• Twilio est configuré pour acheminer les appels via les points de présence canadiens lorsque disponibles.

3. Calendrier de conservation des données

La conservation est appliquée par des scripts automatisés hebdomadaires. Ce ne sont pas des intentions — ils fonctionnent en production et peuvent être audités avec --dry-run.

4. Cycle de vie automatisé des données

Les tâches concrètes qui appliquent le calendrier de conservation ci-dessus :

• Purge hebdomadaire des transcriptions (data_retention.py, dimanche 03h30 UTC) — transcriptions de plus de 90 jours supprimées définitivement. Les résumés générés par IA (sans identifiants directs) sont conservés.
• Anonymisation hebdomadaire des appelants — les enregistrements d'appels de plus de 12 mois voient leur numéro de téléphone remplacé par ANONYMIZED. Les statistiques agrégées restent.
• Nettoyage hebdomadaire des enregistrements — les Twilio recording SIDs de plus de 90 jours sont supprimés via l'API Twilio Recordings, puis la référence est effacée chez nous.
• Purge hebdomadaire des exécutions — les données d'exécution n8n de plus de 90 jours sont supprimées.
• Tests de régression nocturnes — un cron séparé exécute des tests de bout en bout vérifiant que les tâches de rétention et le pipeline de suppression fonctionnent toujours ; des alertes sont envoyées à l'opérateur en cas d'échec.

Toutes les tâches de rétention supportent le mode --dry-run — vous pouvez voir exactement quelles lignes seraient affectées sans exécution.

5. Droit à l'effacement — mécanique de suppression

Quand la suppression est déclenchée

La suppression complète des données (selon le calendrier ci-dessus — 90 jours pour les transcriptions et enregistrements, 12 mois pour les métadonnées) est déclenchée automatiquement lorsque le service d'un client commercial est désactivé pour l'une des raisons suivantes :

• Le client annule son abonnement via le portail de facturation Stripe
• Un remboursement complet est émis — le service est désactivé en quelques secondes après l'événement de remboursement Stripe ; l'horloge de rétention démarre à l'horodatage de désactivation
• Une rétrofacturation (contestation bancaire) est déposée — même comportement qu'un remboursement complet
• Un essai expire sans conversion en plan payant
• Le compte d'un partenaire agence est annulé, orphelinant ses comptes clients (période de grâce de 30 jours avant la désactivation)

Les remboursements partiels (crédits de bonne foi) ne désactivent pas le service ni ne déclenchent la chronologie de suppression.

Ce qui est supprimé (offboarding client commercial)

• Tous les enregistrements d'appels vocaux associés à l'entreprise
• Tous les enregistrements Twilio (fichiers audio)
• Tous les rendez-vous, dossiers personnel, heures d'ouverture, jours fériés et listes de services
• Toutes les données en cache dans Redis
• Le dossier client lui-même

Piste d'audit

Chaque action de suppression est journalisée : horodatage, nombre d'enregistrements, identité de l'opérateur. Le journal d'audit est conservé séparément des données supprimées, de sorte que les événements de suppression restent vérifiables.

Demandes individuelles d'appelants

Si un appelant individuel (et non un client commercial) demande la suppression de ses données, soumettez une demande via notre formulaire de demande de confidentialité (en anglais). Nous vérifions la demande par courriel, puis localisons et supprimons tous les enregistrements associés à votre numéro de téléphone dans un délai de 30 jours.

6. Sous-traitants

Services tiers qui traitent les données dans le cadre de la livraison du service. Données qu'ils voient et leur propre posture de conformité :

Auto-hébergé (pas un sous-traitant) : Redis s'exécute sur notre propre VPS canadien comme cache en mémoire pour l'état temporaire d'appel. Les données expirent automatiquement ; rien ne persiste sur disque.

7. Isolation par locataire

• Chaque entreprise se voit attribuer un identifiant de locataire unique.
• Chaque requête Airtable, clé Redis et exécution de workflow est délimitée par identifiant de locataire. L'accès inter-locataires n'est pas un chemin de code qui existe.
• Les jetons API sont limités aux permissions minimales requises. Les identifiants ne sont jamais partagés entre locataires.
• L'accès au portail est authentifié par locataire avec des jetons JWT portant le claim de locataire.
• Les clés de cache Redis sont nommées par identifiant de locataire avec expiration automatique.

8. Contrôles d'accès

• Jetons API — limités aux permissions minimales requises ; rotés via le store SOPS.
• Permissions de fichiers — secrets stockés avec chmod 600 (accès propriétaire uniquement).
• Aucun identifiant partagé — chaque service utilise sa propre authentification.
• Authentification portail — mots de passe hachés avec bcrypt, JWT à courte expiration.
• Isolation d'environnement — secrets chargés depuis des fichiers d'environnement à permissions restreintes au démarrage du service, jamais soumis au code.

9. Sauvegardes

Des sauvegardes automatisées protègent contre la perte de données. Stockées localement sur notre infrastructure canadienne — aucun transfert transfrontalier.