Empirik lève 21 M$ : prévenir la panne avant le déploiement reste à prouver
Empirik est sortie de l’incubation de Sequoia Capital le 1er septembre 2026 en tant que société indépendante, après avoir levé 21 millions de dollars en amorçage, comme l’a rapporté TechCrunch. La jeune entreprise veut intervenir avant la mise en production : son logiciel modélise les dépendances d’une infrastructure et évalue les conséquences possibles d’un changement.
Depuis ce lancement du 1er septembre, le produit est présenté comme déjà utilisé dans des environnements d’entreprise pour signaler ou bloquer certaines modifications risquées. Mais ni un taux de prédiction ni une réduction mesurée des incidents n’ont été publiés : Empirik démontre l’existence d’une couche de contrôle en amont, pas encore sa capacité à prévenir les pannes avec une fiabilité quantifiée.
Un amorçage de 21 M$ pour sortir de l’incubation
La société emploie une formulation légèrement plus large que le montant arrondi dans la presse. L’annonce officielle d’Empirik fait état de plus de 21 millions de dollars, menés par Sequoia et S32 avec Canapi Ventures et Alumni Ventures, et indique que le produit fonctionne déjà en production chez plusieurs entreprises.
Le projet avait été incubé en 2023 par Sequoia autour d’Avon Puri et de Sudheer Dhurjati, deux responsables de l’infrastructure du fonds. La société est désormais dirigée par Kartik Chandrayana, ancien responsable de produits d’observabilité chez Salesforce puis directeur produit de Quantum Metric. La valorisation, la répartition du capital et l’usage détaillé des fonds n’ont pas été rendus publics.
Le contrôle se déplace avant le changement
L’écart avec l’observabilité classique tient d’abord au moment où l’analyse intervient. Les journaux, métriques et traces décrivent le comportement d’un système en fonctionnement ; ils permettent de détecter une dégradation et d’en rechercher la cause. Empirik prend pour signal principal le changement lui-même, avant sa fusion ou son déploiement.
Le processus revendiqué commence par l’interprétation de l’intention de l’ingénieur ou de l’agent logiciel. Empirik cherche ensuite les ressources et les équipes susceptibles d’être touchées, calcule le rayon d’impact, puis peut laisser avancer une opération jugée peu risquée, lui appliquer des garde-fous ou transmettre les cas les plus dangereux à une personne.
Ce contrôle ne remplace donc pas la télémétrie de production. Pour estimer correctement les effets en cascade, le produit doit connaître l’état réel de l’environnement et ses dépendances. L’observabilité peut alimenter cette représentation et rester nécessaire pour détecter les incidents que l’évaluation préalable n’aurait pas anticipés.
Une carte unifiée aujourd’hui, davantage d’autonomie demain
Le socle du produit est un graphe opérationnel couvrant les systèmes sur site, les clouds et les services SaaS. Il doit rapprocher les états déclarés dans l’Infrastructure as Code des ressources effectivement déployées, tout en intégrant des relations moins visibles comme les politiques IAM, les tables de routage, les quotas et les groupes de sécurité.
Les fonctions présentées comme disponibles comprennent la détection de dérive, le calcul du rayon d’impact, l’identification des responsables affectés ainsi que le signalement ou le blocage des changements risqués. Le même contexte peut servir à l’examen d’une architecture, d’une migration, d’un incident, d’une opération de sécurité ou d’un provisionnement.
L’autonomie complète reste en revanche une trajectoire. Le système répond aujourd’hui à des questions et intervient dans les contrôles de changement ; Empirik prévoit qu’il puisse ensuite valider des actions, puis les exécuter lorsque ses clients lui accorderont davantage d’autorité. L’expression « ingénieur d’infrastructure autonome » désigne ainsi une ambition plus large que les capacités documentées au lancement.
Des utilisateurs déclarés, mais peu de détails comparables
Empirik nomme Guardant Health parmi ses utilisateurs et évoque également un groupe mondial de biens de consommation du Fortune 50 ainsi qu’une entreprise de services financiers du Fortune 500. Ces deux dernières références restent anonymes. Leur périmètre, la durée des déploiements et le nombre de changements évalués ne sont donc pas vérifiables publiquement.
Ces usages déclarés montrent que le logiciel dépasse le stade d’une démonstration isolée, sans constituer une validation indépendante de sa promesse centrale. Les informations disponibles ne précisent pas combien de changements dangereux ont été détectés avant production, combien d’alertes étaient injustifiées ni combien d’incidents ont effectivement été évités.
La prévention des pannes reste à mesurer
La question décisive n’est pas seulement de construire une carte de dépendances, mais de classer correctement le risque associé à chaque modification. L’analyse de TechTimes relève l’absence de données publiques sur la précision des prédictions, le taux de faux positifs et les lacunes de couverture dans les environnements partiellement instrumentés.
Ces mesures distingueraient une cartographie utile d’un système fiable de prévention. Trop de faux positifs peuvent ralentir les déploiements et banaliser les alertes ; des faux négatifs laissent passer les changements que le produit est censé intercepter. Une dépendance absente du graphe peut également fausser le calcul du rayon d’impact, même si le reste de la carte est exact.
Le financement, la sortie de l’incubation et l’existence d’utilisateurs déclarés sont établis au lancement. Empirik documente aussi le déplacement du contrôle vers l’amont et les fonctions qui soutiennent ce modèle. Il reste à publier des résultats comparables sur la prédiction des incidents, leur réduction réelle, les erreurs de classement et la couverture d’infrastructures hétérogènes.
À lire aussi:
Abonnez-vous à notre newsletter
Recevez directement les dernières actualités sur le Web3, l’IA et les cryptomonnaies.