Raisetalk est-il sécurisé ? Ce que nous mesurons, corrigeons et publions

Une base saine hier ne l'est plus aujourd'hui

Un logiciel ne se dégrade pas parce qu'on y touche. Il se dégrade parce que le monde autour de lui bouge. Vous n'avez pas modifié une ligne de code depuis trois semaines, et pourtant votre produit est peut-être vulnérable ce matin : une CVE vient d'être publiée sur une dépendance transitive que vous n'avez jamais choisie explicitement, l'image de base de votre conteneur embarque une bibliothèque système qui vient de basculer en fin de support, un binaire livré par un fournisseur intègre une version figée d'une librairie tierce, un réglage cloud considéré comme acceptable il y a un an est devenu une mauvaise pratique documentée.

Le rythme des publications de vulnérabilités dépasse aujourd'hui la centaine par jour, tous éditeurs confondus. À cette cadence, la question pertinente pour évaluer un fournisseur n'est pas « êtes-vous certifiés ? ». C'est : que se passe-t-il chez vous entre l'instant où une vulnérabilité est publiée et l'instant où elle est corrigée ? Combien de temps, par quel mécanisme, avec quelle preuve, et qui décide qu'elle est corrigée.

Cette question nous concerne particulièrement. Raisetalk traite des enregistrements d'appels, des transcriptions, des données personnelles de clients finaux qui n'ont jamais entendu parler de nous : ils ont simplement appelé leur banque, leur assureur ou leur fournisseur d'énergie. La confiance qu'on nous accorde est une confiance déléguée, et ce type de confiance se démontre plutôt qu'il ne se déclare.

Cet article décrit donc la mécanique, pas l'intention. Ce que nous mesurons, à quelle fréquence, ce qui se passe quand une alerte tombe, ce que nous publions, et enfin comment cette approche se compare aux deux autres réponses classiques du marché : la certification et le test d'intrusion.

Ce que nous analysons, en permanence

Nous nous appuyons sur Aikido Security comme plateforme d'analyse et de protection. Le choix tient à une raison simple : la couverture. Beaucoup d'outils font très bien une chose, l'analyse statique du code ou le contrôle de la posture cloud. Le problème, c'est qu'un attaquant ne choisit pas sa porte d'entrée selon le découpage de votre outillage. Une clé d'API laissée dans un fichier de configuration, une CVE dans un paquet système d'une image de conteneur et un rôle IAM trop large sur un compte de service se valent parfaitement de son point de vue.

Six surfaces sont donc suivies, en continu.

Ce dernier point mérite une précision, parce qu'il est rarement fait. Un scanner qui s'arrête à la page de connexion n'analyse que la vitrine. Nous avons donc ouvert au scanner un accès authentifié à l'API, afin qu'il explore aussi ce qui se trouve derrière l'authentification, là où se trouvent les routes qui manipulent réellement les données. C'est plus inconfortable, puisque cela produit mécaniquement plus de findings. C'est précisément pour cela que c'est utile.

Ce qui protège pendant que le code tourne

Analyser, c'est trouver ce qui pourrait être exploité. Protéger, c'est arrêter ce qui est en train de l'être. Les deux ne se substituent pas l'un à l'autre, et nous utilisons deux briques distinctes pour la seconde moitié du travail.

Un pare-feu applicatif embarqué dans l'API. Zen ne s'exécute pas devant l'application comme un WAF classique posé en frontal : il s'exécute dans le processus applicatif, ce qui lui donne accès au contexte que le frontal n'a pas. Il ne voit pas seulement une chaîne suspecte dans une requête HTTP, il voit la requête SQL réellement construite, la commande réellement exécutée, le chemin de fichier réellement ouvert. Il peut donc distinguer une chaîne qui ressemble à une injection d'une chaîne qui en produit effectivement une. Chez nous, il tourne en mode blocage depuis l'automne 2025, et non en simple observation : une tentative détectée est interrompue, pas seulement journalisée.

C'est une décision qui a un coût, et il faut le dire : un pare-feu en mode blocage peut, en théorie, interrompre une requête légitime. Nous l'assumons, et c'est aussi pourquoi les montées de version de cette brique sont traitées avec la même prudence qu'un changement fonctionnel, en vérifiant ce qu'elles modifient dans les décisions de blocage avant de les déployer.

Le contrôle de la posture des postes de travail. La deuxième brique porte sur nos propres machines, celles depuis lesquelles nous développons et administrons la production. Chiffrement du disque, verrouillage de session, mises à jour du système, antivirus actif : ces contrôles sont vérifiés en continu sur chaque poste. Ce n'est pas de la conformité décorative. Une plateforme irréprochable administrée depuis un portable non chiffré et laissé ouvert dans un train reste une plateforme vulnérable, et l'attaquant qui vise un éditeur de logiciel a rarement le produit pour première cible.

Ce qui se passe quand une alerte tombe

C'est ici que se joue la différence entre une plateforme d'analyse achetée et une pratique de sécurité réelle. Un outil qui remonte deux cents alertes produit deux cents alertes. Il ne produit pas de la sécurité. La sécurité commence à l'étape suivante, celle que personne ne montre en démonstration.

Notre processus est écrit et suivi à chaque fois, dans le même ordre.

1. Le regroupement par cause racine. Un groupe de trente-six findings n'est presque jamais trente-six problèmes. C'est souvent une seule ligne dans un fichier de verrouillage de dépendances, projetée sur trois images de conteneurs et deux dépôts. La première étape consiste donc à séparer la cause racine unique des surfaces impactées, et à dire combien de corrections distinctes sont réellement nécessaires. C'est ce qui évite de confondre le volume d'alertes avec la charge de travail, et de traiter en urgence trente-six symptômes au lieu d'un problème.

2. L'ouverture d'un ticket, avec son échéance. Chaque groupe traité donne lieu à un ticket dans le dépôt concerné, avec sa sévérité et son échéance de traitement. Rien ne vit dans un tableau de bord seul : ce qui n'a pas de ticket n'a pas de responsable, et ce qui n'a pas d'échéance n'a pas de priorité.

3. La vérification dans notre propre code. C'est l'étape que le scanner ne peut pas faire à notre place. Une CVE annoncée sur une bibliothèque ne dit pas si le code vulnérable est atteignable depuis le nôtre. Nous allons lire les fichiers concernés, confirmer la version réellement installée, la contrainte réellement déclarée, et les appelants réels. Une vulnérabilité de type SSRF dans une fonction que nous n'appelons jamais n'a pas la même urgence qu'une désérialisation atteignable depuis une route publique. Cette vérification produit parfois la conclusion inverse de l'alerte : faux positif, code mort, ou correction déjà en place. Dans ce cas, la décision est tracée avec son motif, jamais par un simple classement sans suite.

4. Le correctif, et tout ce qui va avec. Un plan de remédiation ne s'arrête pas au changement de version. Il inclut explicitement les étapes hors code : reconstruction de l'image, rotation d'un secret, réécriture d'historique si un identifiant a été exposé, redémarrage du service concerné. Un secret retiré du code source mais toujours valide chez le fournisseur n'est pas un secret corrigé.

5. La vérification après déploiement, puis la fermeture par un humain. Nous vérifions que le correctif est effectivement présent dans ce qui tourne, et pas seulement dans ce qui est commité. Une image reconstruite mais non déployée, un trafic resté épinglé sur l'ancienne révision après un retour arrière : ces écarts sont classiques, et ils transforment une correction en illusion de correction. Ce n'est qu'ensuite qu'un être humain ferme le ticket.

Le socle de durcissement, dans le détail

Une mécanique de détection ne vaut que par le socle sur lequel elle s'applique. Voici, sans exhaustivité, les partis pris qui régissent aujourd'hui l'infrastructure de Raisetalk. Ils ne sont pas déclaratifs : chacun est vérifié en continu par les analyses décrites plus haut, et un écart devient une alerte.

• Aucun conteneur ne s'exécute avec les privilèges de l'administrateur. Les processus maîtres comme les processus de travail tournent sous un compte non privilégié, et les services écoutent sur des ports non privilégiés.
• Les images ne contiennent aucun binaire à bit SUID, et un contrôle fait échouer la construction de l'image si l'un d'eux y apparaît. Une étape d'installation ajoutée plus tard pourrait en réintroduire un sans que rien ne le signale : un durcissement qui ne se surveille pas lui-même se perd toujours à la mise à jour suivante.
• Le démarrage sécurisé est actif sur les machines virtuelles, de sorte que la chaîne de démarrage est vérifiée avant que le système ne se charge.
• L'accès d'administration passe par l'identité, jamais par une clé partagée. Authentification via l'identité cloud, clés SSH de projet bloquées, accès aux machines par tunnel authentifié plutôt que par exposition d'un port d'administration.
• Chaque service s'exécute avec un compte dédié, limité aux droits dont il a réellement besoin, et jamais avec un compte par défaut : ces derniers portent, par construction, des rôles beaucoup trop larges.
• La base de données impose elle-même le chiffrement des connexions, plutôt que de le laisser au bon vouloir du client qui s'y connecte.
• Le site public applique une politique de sécurité de contenu stricte, jusqu'à interdire les styles en ligne : une contrainte réelle pour ceux qui écrivent les composants, et une surface d'injection en moins.

Aucun de ces points n'est spectaculaire pris isolément. C'est leur combinaison, et surtout le fait qu'ils soient vérifiés en permanence plutôt qu'une fois à l'installation, qui constitue le travail réel.

Où nous en sommes, au 19 août 2026

À la date de publication de cet article, le tableau de bord ne comporte aucune alerte ouverte sur l'ensemble du périmètre. Les rapports de conformité générés par la plateforme donnent les résultats suivants.

La plateforme situe par ailleurs Raisetalk dans les 5 % d'applications les mieux sécurisées de son parc. C'est une comparaison relative fournie par un tiers, nous la citons comme telle.

La transparence : le rapport, sur demande

Un fournisseur qui affirme que tout va bien vous demande de le croire. Nous préférons vous laisser regarder.

Le badge présent en pied de page de toutes les pages de ce site ouvre un formulaire de demande d'accès au rapport d'audit de sécurité. Le rapport est généré à partir de l'état réel de la plateforme au moment de la demande, et non depuis un document figé rédigé une fois pour toutes : c'est la même source que celle qui produit les chiffres ci-dessus.

Pourquoi sur demande plutôt qu'en accès libre ? Parce qu'un rapport de sécurité décrit un périmètre technique, et que savoir à qui on le communique fait partie de l'hygiène élémentaire. Le formulaire est court et la demande est traitée rapidement.

C'est aussi, pour nous, un engagement à sens unique. Publier un badge qui donne accès à une mesure indépendante de notre état de sécurité, c'est accepter par avance qu'un mauvais mois soit visible. C'est précisément ce qui rend l'information utile le reste du temps.

Les autres approches, et pourquoi elles viennent après

Deux réponses dominent le marché quand un acheteur pose la question de la sécurité. Elles sont l'une et l'autre légitimes, et l'une et l'autre insuffisantes seules. Notre position tient en un mot : l'ordre.

La certification ISO 27001

ISO/IEC 27001 certifie un système de management de la sécurité de l'information. Un organisme accrédité vérifie que vous avez identifié vos risques, défini des mesures, documenté vos procédures, et que vous faites vivre l'ensemble. Le certificat est valable trois ans, avec des audits de surveillance annuels. C'est un travail sérieux, qui structure durablement une organisation, et c'est un signal fort pour un acheteur.

Ses limites tiennent à sa nature même, et elles n'ont rien de polémique. L'audit procède par échantillonnage, à une date donnée. Il valide un système de management, pas l'état technique de votre produit à l'instant où votre prospect lit le certificat. Rien dans un certificat obtenu en mars ne vous renseigne sur la vulnérabilité critique publiée en octobre sur une dépendance de l'application. Le certificat atteste que l'organisation dispose d'un processus pour la traiter, ce qui est très différent d'attester qu'elle l'a traitée.

C'est une photographie, prise par un professionnel, avec un excellent appareil. Elle reste une photographie.

Le test d'intrusion (pentest)

Le test d'intrusion apporte ce qu'aucun scanner ne sait produire : l'intelligence d'un attaquant humain. Enchaîner trois faiblesses individuellement mineures pour obtenir un accès qui ne devrait pas exister, détourner une logique métier parfaitement conforme au code, accéder à l'objet d'un autre client en manipulant un identifiant : cela ne se détecte pas par analyse de motifs.

Cependant, sa limite est budgétaire, et elle est structurelle. On achète un nombre de jours, donc on définit un périmètre. Tout ce qui est hors périmètre n'est pas testé, et le rapport n'en fera souvent pas état, ou en tout petit... Il décrira ce qui a été trouvé là où on a cherché. Comme la certification, le test vaut pour une date, une version et surtout un périmètre limité. Le déploiement du mois suivant en périme une partie.

Les trois approches, côte à côte

Ces trois colonnes ne se remplacent pas. Elles se complètent, dans cet ordre. Se faire certifier sans avoir de contrôle continu, c'est documenter proprement un processus qu'on ne sait pas exécuter. Commander un test d'intrusion sur un périmètre où traînent des dépendances vulnérables connues, c'est payer au prix d'un expert la découverte de ce qu'un scanner trouve gratuitement en une nuit. Et le commander sur un périmètre étroit, choisi précisément parce qu'on le maîtrise déjà, c'est acheter une bonne nouvelle plutôt qu'une information : elle est décidée au moment où l'on rédige le périmètre, pas au moment du test. Un test d'intrusion utile est celui dont le périmètre a été choisi pour sa difficulté, et dont l'étendue est donnée en même temps que la conclusion.

Notre séquence est donc celle-ci : d'abord la mesure permanente et la correction systématique, parce que c'est ce qui protège réellement les données de nos clients aujourd'hui. Une certification ISO 27001 est envisagée pour la suite, et un test d'intrusion externe figure à notre feuille de route : ils viendront valider et compléter des fondations existantes, pas les remplacer ni en tenir lieu.

Ce que le contrôle continu ne remplace pas

Il serait malhonnête de terminer sans dire où s'arrête ce que nous décrivons ici.

Une plateforme d'analyse ne connaît pas votre métier. Elle sait qu'une requête SQL est construite par concaténation. Elle ne sait pas qu'un utilisateur d'une équipe ne doit jamais voir les évaluations d'une autre équipe. Ces règles-là sont propres à notre produit, et aucune base de vulnérabilités ne les contient. C'est pourquoi nous maintenons en interne notre propre modèle de menace : les unités de déploiement, les surfaces d'entrée, les frontières de confiance, et les règles métier qui ne doivent jamais céder. Il est relu et mis à jour comme du code, et il sert de carte quand nous cherchons ce qu'aucun outil ne cherchera à notre place.

Un score de conformité n'est pas une garantie. Il indique qu'aucun problème connu ne subsiste sur le périmètre observé. C'est appréciable, et cela ne dit rien des vulnérabilités qui ne sont pas encore publiques. Personne ne peut promettre l'inverse, et il faut se méfier de ceux qui le font.

La sécurité reste une chaîne. Elle inclut nos sous-traitants, nos fournisseurs de modèles d'IA, l'hébergeur, et l'usage qui est fait de la plateforme par vos propres équipes. C'est d'ailleurs pour cela que le contrôle d'accès par rôles et périmètres et la pseudonymisation des données personnelles font partie du même sujet que les vulnérabilités : ils déterminent ce qui reste protégé le jour où quelque chose cède ailleurs.

Le mot de la fin

Nous aurions pu écrire un article court : « zéro vulnérabilité, treize référentiels, top 5 % ». Il aurait été exact, et il n'aurait rien prouvé. Les chiffres qui comptent en sécurité ne sont pas ceux qu'on affiche, ce sont ceux qu'on peut expliquer : d'où ils viennent, ce qu'ils couvrent, ce qu'ils laissent de côté, et ce qui se passe le jour où ils se dégradent.

La sécurité d'un logiciel n'est pas un état, c'est un rythme. Elle ne se prouve pas par un document annuel, mais par la capacité à traiter, semaine après semaine, ce que la mesure fait remonter, y compris quand c'est inconfortable, y compris quand cela oblige à reconstruire une machine ou à retoucher un composant qui fonctionnait très bien.

Et parce qu'une affirmation de fournisseur ne vaut jamais une vérification d'acheteur : le rapport est en bas de cette page.

Vérifier par vous-même

• Demander le rapport d'audit de sécurité : accéder au formulaire, ou cliquer sur le badge en pied de page.
• Nos réponses sur les données et le RGPD : la foire aux questions
• Nous poser une question précise : www.raisetalk.com/contact

Les chiffres cités dans cet article correspondent à l'état constaté le 19 août 2026. Ils évoluent : c'est même tout leur intérêt. Un tableau de bord de sécurité qui n'a pas bougé depuis six mois n'est pas le signe d'un produit stable, c'est le signe d'une mesure à l'arrêt. La bonne question à poser à un fournisseur, la nôtre incluse, n'est donc pas « votre score est-il bon aujourd'hui ». C'est « que se passe-t-il chez vous le jour où il ne l'est plus ».