Interview de Thomas Pons, fondateur de Wisec
Wisec est une plateforme SaaS qui permet de prouver l’intégrité d’une chaîne de développement logiciel.
Aujourd’hui, les entreprises utilisent beaucoup d’outils de sécurité, mais aucune ne peut démontrer de manière fiable qu’un build n’a pas été altéré.
Wisec génère une preuve cryptographique infalsifiable à chaque build, directement exploitable en audit ou en cas d’incident.
Durant mes années en tant que SysOps/DevOps, j’ai constaté un manque de sécurité autour des pipelines CI/CD, qui sont pourtant une surface critique.
Au départ, j’ai commencé à construire Wisec avec une approche assez classique autour de la détection. Mais en avançant, je me suis rendu compte que ces outils existaient déjà, et en grand nombre.
Le vrai problème n’était pas de détecter, mais de prouver.
Aujourd’hui, même avec de bons outils, les entreprises ne sont pas capables de relier les builds entre eux ni de fournir facilement des preuves fiables de ce qui a été exécuté, surtout plusieurs semaines ou mois après.
C’est à ce moment-là que j’ai fait évoluer Wisec vers une approche de notarisation : créer une preuve cryptographique pour chaque build, et rendre cette preuve exploitable dans le temps, notamment pour les audits et les investigations.
Aujourd’hui, Wisec est en phase de déploiement et d’expérimentation avec des équipes techniques, notamment des profils DevOps, RSSI et CTO.
Nous sommes encore en phase d’adoption initiale, avec des premiers utilisateurs et des discussions en cours pour des pilotes.
La cible principale est constituée d’entreprises soumises à des contraintes de conformité comme NIS2 ou SOC2, où la traçabilité devient un enjeu clé.
Wisec est proposé en SaaS avec un modèle par abonnement, allant de gratuit à des offres pour équipes et organisations.
À terme, le modèle pourra évoluer vers des offres enterprise avec des besoins spécifiques en conformité, intégration et gouvernance.
La plateforme repose sur un agent léger en Go qui s’intègre directement dans les pipelines CI/CD.
Les preuves sont signées cryptographiquement et ancrées dans un stockage immuable, avec une architecture cloud souveraine basée en France.
L’objectif est d’avoir une solution robuste, simple à intégrer et indépendante des outils existants.

Aujourd’hui, le principal enjeu est d’accélérer le go-to-market et de structurer l’adoption :
La technologie est en place, l’enjeu est désormais clairement l’adoption et la traction marché.
Aujourd’hui, il existe deux grandes catégories d’acteurs.
D’un côté, des outils comme Snyk ou Dependabot qui détectent les vulnérabilités.
De l’autre, des initiatives comme Sigstore ou le framework SLSA qui adressent la signature et la provenance.
Le problème, c’est qu’aucune de ces solutions ne fournit une preuve globale, exploitable et simple à utiliser dans un contexte réel d’audit ou d’incident.
Wisec se positionne différemment : nous ne remplaçons pas les outils existants, nous les certifions et les relions entre eux.
Notre valeur ajoutée est d’apporter une preuve complète, vérifiable et durable dans le temps, là où aujourd’hui les entreprises disposent uniquement de signaux techniques dispersés.
Dans un an, l’objectif est d’avoir validé Wisec comme une brique essentielle de la conformité logicielle, avec des déploiements chez des entreprises soumises à des exigences fortes comme NIS2 ou SOC2.
Nous voulons également structurer un écosystème de partenaires, notamment des cabinets de conseil et des acteurs DevSecOps, pour intégrer Wisec dans des démarches de conformité globales.
Plus largement, notre ambition est de faire évoluer le marché vers une nouvelle approche : passer d’une logique de détection à une logique de preuve dans la sécurité des pipelines logiciels.
Le jour du lancement officiel de Wisec, le site est devenu indisponible à cause d’un incident sur une infrastructure cloud.
C’est un moment assez marquant, parce que tout était prêt côté produit et communication, mais la disponibilité n’était pas au rendez-vous.
Ça m’a rappelé à quel point même des architectures modernes restent dépendantes de fournisseurs externes.
Depuis, j’ai renforcé les aspects de résilience et de monitoring pour mieux anticiper ce type de situation.
Ne pas sur-construire trop tôt, et confronter rapidement son produit au marché.
On peut passer des mois à perfectionner une solution, mais la vraie validation vient toujours des utilisateurs.
prochain article