Sécurité et protection des données

Une automatisation déplace vos données par construction. Elle lit dans vos systèmes, transforme de l’information, appelle des services et réécrit des résultats. La façon honnête de parler de sécurité consiste donc à dire où vont les données à chacun de ces moments, ce qui leur est retiré avant qu’elles ne circulent, et ce qui reste vérifiable ensuite.

Cette page énonce les positions que transtorm.ai applique réellement. Elle couvre le lieu physique des données, ce qui se passe avant qu’une information n’atteigne un modèle externe, la gestion des accès et des secrets, la journalisation, notre posture RGPD, et la propriété du code à la fin. Notre page méthode décrit la séquence de projet dans laquelle ces positions s’inscrivent.

Le traitement local passe en premier

Nous privilégions le traitement local des données partout où c’est possible. Beaucoup des opérations qu’exécute une automatisation métier, comme lire un fichier, vérifier une condition, rapprocher deux sources, générer un document ou déclencher une notification, ne nécessitent aucun service externe. Tant que ces étapes restent locales, il n’y a pas de transfert à sécuriser, pas de sous-traitant à auditer et pas de question de conservation à trancher.

Cette préférence est une contrainte de conception, pas une formule commerciale. Elle change l’architecture que nous proposons, et elle écarte parfois un service qui aurait été pratique.

Ce qui atteint un modèle externe, et ce qui n’y va jamais

Lorsqu’une ressource externe est réellement nécessaire, les données qui lui sont transmises ont été entièrement anonymisées au préalable. Aucune donnée sensible n’est envoyée à ces services.

L’anonymisation se produit à l’intérieur du flux, avant l’appel, et elle relève de la conception du connecteur plutôt que d’un filtre ajouté à la fin. La conséquence compte en pratique : ce que voit le modèle externe est une charge utile épurée, et les informations identifiantes restent de votre côté de la frontière.

Aucune de ces données ne sert à entraîner un modèle. Nous n’entraînons aucun modèle d’intelligence artificielle, ni avec les données de vos systèmes, ni avec celles que ce site collecte, et notre politique de confidentialité l’énonce pour ces dernières.

Certains de nos systèmes poussent l’argument jusqu’au bout et n’utilisent aucun modèle de langage. Notre application d’audit de terrain calcule ses onze champs dérivés avec un moteur déterministe, ne dépend d’aucun modèle et ne réclame aucune clé d’API, précisément pour que nous puissions montrer à un client d’où vient chaque chiffre.

L’auto-hébergement, quand les données ne doivent pas sortir des murs

Pour les clients qui en ont besoin, l’ensemble du système peut tourner sur leur propre infrastructure.

Notre borne d’accueil patient est auto-hébergée sur les machines du cabinet, conteneurisée avec Docker, et aucune donnée n’est envoyée vers un cloud externe. Son compagnon mobile est sécurisé par la présence physique plutôt que par un compte ou un lien partageable : le QR code affiché en salle d’attente porte un jeton quotidien calculé à partir d’un secret et de la date, si bien qu’il ne s’obtient qu’en se tenant devant l’écran physique. Notre workflow de signature électronique repose sur Documenso, une plateforme open source que nous hébergeons nous-mêmes pour la démonstration publique, et le même montage s’installe dans les locaux de la clinique, où les documents signés restent alors.

L’auto-hébergement n’est pas sans conséquence. Il déplace la charge d’exploitation, c’est-à-dire les sauvegardes, les mises à jour et la disponibilité, vers le client. Nous le disons pendant l’audit plutôt qu’après, et l’arbitrage se tranche avec les faits sur la table.

Moindre privilège, secrets et séparation des environnements

Chaque micro-processus ne dispose que des accès nécessaires à sa propre exécution, ce qui limite la portée d’un incident si un composant est compromis. Les identifiants sont chiffrés, tournés régulièrement, et jamais partagés entre environnements. Le développement, la préproduction et la production restent strictement isolés, de sorte qu’un test ne puisse jamais atteindre une donnée réelle ni un destinataire réel.

Le découpage du processus en micro-processus courts aide également ici. Une étape dont le seul rôle consiste à générer un document n’a aucune raison de détenir les identifiants de la messagerie, et elle ne les détient pas.

Tout ce qui compte est journalisé

Un système automatisé que l’on ne peut pas auditer est une boîte noire, et une boîte noire en production finit toujours par coûter cher. Chaque action est donc journalisée avec son horodatage, son contexte et son résultat.

Ce journal répond aux questions qu’un incident pose réellement. Que s’est-il passé, quelle décision a été prise, pourquoi le flux s’est-il arrêté, quelle étape a échoué, peut-on relancer sans créer de doublon, et qui faut-il alerter. Il sert aussi la conformité, car un auditeur qui réclame la preuve d’un contrôle reçoit un enregistrement écrit sur le moment plutôt que reconstitué après coup. Notre cas d’usage de contrôle bancaire existe largement parce que les auditeurs du client exigeaient des preuves que le travail manuel rendait difficiles à reconstruire.

La validation humaine sur les actions sensibles

La traçabilité dit ce qui s’est passé. La validation humaine décide si cela doit se passer.

La validation manuelle est optionnelle, et elle est activée là où les règles métier l’exigent. Pour les actions à impact métier, financier ou opérationnel significatif, le système demande avant d’agir. Cela prend la forme d’une confirmation avant une action sensible, d’une approbation avant un envoi ou une exécution, d’un blocage automatique quand un cas est ambigu, d’une alerte au franchissement d’un seuil ou d’une règle critique, et d’une trace journalisée pour chaque décision importante. Les notifications sont instantanées et un délai d’expiration se déclenche automatiquement, afin qu’une validation en attente ne bloque jamais silencieusement une file.

Notre posture RGPD

L’hébergement se fait en Europe. Un accord de traitement des données est signé avec chaque sous-traitant, y compris les fournisseurs de modèles d’IA, et la liste des sous-traitants vous est communiquée avant tout déploiement plutôt que découverte ensuite. La situation RGPD de votre cas précis est examinée pendant l’audit, c’est-à-dire au moment où changer d’architecture coûte encore peu.

transtorm.ai est responsable du traitement pour les données personnelles collectées via ce site. Pour les données clients traitées dans les projets qu’elle réalise, le rôle de chaque partie au sens du RGPD est fixé par écrit dans le contrat de projet, avant toute construction. Lorsqu’un prestataire se situe hors de l’Union européenne ou de l’Espace économique européen, nous appliquons des garanties appropriées telles que les clauses contractuelles types de la Commission européenne, accompagnées de mesures techniques et organisationnelles adaptées. Les données personnelles ne sont pas conservées plus longtemps que nécessaire, puis elles sont supprimées ou anonymisées, les journaux techniques étant conservés pendant une durée limitée et proportionnée à la sécurité et à l’exploitation.

Vous disposez des droits habituels d’accès, de rectification, d’effacement, de limitation, d’opposition et de portabilité, et lorsqu’un traitement repose sur votre consentement, vous pouvez le retirer. Vous exercez ces droits en écrivant à info@transtorm.ai. Vous pouvez également introduire une réclamation auprès d’une autorité de contrôle compétente, dont l’Andmekaitse Inspektsioon estonienne. Le texte complet figure dans notre politique de confidentialité.

Ce site lui-même

Le site est édité par transtorm.ai , immatriculée en Estonie sous le code de registre 17443658, à l’adresse Harju maakond, Tallinn, Kesklinna linnaosa, Pärnu mnt 388b, 10131. Il est hébergé par OVH SAS, 2 rue Kellermann, 59100 Roubaix, France. Les mentions légales portent les informations d’édition complètes.

Nous collectons des données d’identité et de contact lorsque vous nous écrivez, des données techniques comme l’adresse IP, le type d’appareil et le navigateur, ainsi que des données d’usage sur les pages visitées. Nous ne cherchons pas à collecter de données personnelles sensibles, y compris de données de santé, via ce site. Ce site dépose une seule catégorie de cookies qui lui soit propre, la mesure d’audience décrite dans notre politique de confidentialité, et elle ne se charge qu’après votre acceptation dans la bannière de consentement. Cette même politique nomme les tiers que ce site appelle et explique comment les bloquer depuis votre navigateur.

Ce que nous construisons vous appartient

Les développements spécifiques, c’est-à-dire le code et les workflows construits pour vous, vous appartiennent dès leur paiement, et l’article 7 de nos conditions générales le prévoit, que le devis le répète ou non. Deux choses restent en dehors de ce transfert. Les outils tiers gardent les licences de leurs propres éditeurs, et les composants réutilisables que nous détenions avant votre projet ou que nous avons développés indépendamment de lui restent les nôtres, sous licence tant que vous exploitez le système. Les deux vous sont indiqués avant toute construction.

La maintenance n’est pas obligatoire. Elle se résilie avec un préavis d’un mois, le système continue de fonctionner sans nous, et nous fournissons une documentation assez précise pour qu’un autre prestataire le reprenne. La propriété et la réversibilité rendent le reste de cette page vérifiable au lieu de simplement promis : un système qui vous appartient est un système que vous pouvez inspecter, déplacer ou arrêter.

Posez-nous la question qui dérange

Si une exigence particulière s’applique à votre secteur, à vos auditeurs ou à votre délégué à la protection des données, posez la question avant le démarrage du projet. L’audit est le bon moment pour y répondre, et un non clair rend plus service qu’un oui vague.