Empirik lève 21 M$ pour arrêter les pannes avant la première alerte
Le 1er septembre 2026, Empirik est sortie de la discrétion après une incubation au sein de Sequoia, avec plus de 21 millions de dollars de financement et un produit destiné à évaluer les changements d’infrastructure avant leur exécution. L’annonce officielle d’Empirik désigne Sequoia et S32 comme chefs de file, aux côtés de Canapi Ventures et Alumni Ventures, et présente des déploiements en production chez Guardant Health ainsi que dans plusieurs grandes entreprises non nommées.
À la même date, Empirik est devenue une société indépendante avec l’ambition d’intervenir avant la première alerte : comprendre l’intention d’une modification, retrouver ses dépendances et estimer son rayon d’impact avant le déploiement. Le portrait publié par TechCrunch confirme une levée d’amorçage de 21 millions de dollars et une incubation commencée en 2023, mais aucune donnée publique ne démontre encore une baisse effective des pannes.
Trois ans d’incubation avant la création d’une société indépendante
Empirik trouve son origine dans un projet lancé en 2023 par Avon Puri et Sudheer Dhurjati, alors responsables informatiques chez Sequoia. Leur idée consistait à déplacer l’analyse de fiabilité vers le moment où un changement est envisagé, au lieu d’attendre qu’un système en production émette des signaux de dégradation.
Kartik Chandrayana a été recruté comme directeur général en 2026. Son parcours comprend la direction de produits chez Quantum Metric et des responsabilités dans l’observabilité chez Salesforce. La levée accompagne donc à la fois la constitution d’une entreprise indépendante et la commercialisation d’un produit auparavant développé dans le cadre de l’incubation.
Les déploiements cités établissent que le logiciel est utilisé dans des environnements d’entreprise. Ils ne renseignent toutefois ni leur durée, ni le nombre de changements examinés, ni la part des décisions réellement automatisées. Le lancement commercial est confirmé ; l’ampleur de l’adoption reste difficile à établir à partir des seules informations publiques.
Le changement devient le premier signal analysé
Empirik se concentre sur l’action envisagée plutôt que sur le symptôme d’un incident déjà engagé. Le produit doit traiter des événements comme un déploiement, une modification de configuration, un changement de permission IAM, une règle de routage ou une opération de provisionnement, tout en captant l’intention de l’ingénieur ou de l’agent logiciel à l’origine de l’action.
Le système est présenté comme construisant un modèle vivant des relations entre les composants sur site, dans le cloud et dans les services SaaS. Il doit y intégrer des dépendances qui ne figurent pas toujours dans l’Infrastructure as Code ou dans les topologies d’exécution, notamment les politiques IAM, les tables de routage, les quotas et les groupes de sécurité.
Le cycle annoncé suit cinq étapes :
- un humain ou un agent propose une modification et en fournit l’intention ;
- Empirik rapproche cette action de l’état observé de l’infrastructure ;
- le système calcule les ressources, services et propriétaires susceptibles d’être touchés ;
- il autorise les opérations jugées peu risquées, ajoute des garde-fous ou transmet les cas sensibles à un humain ;
- la décision intervient avant la fusion ou le déploiement, donc avant qu’une éventuelle panne ne produise sa première alerte.
Le verbe « arrêter » du titre décrit ainsi l’objectif du contrôle préalable : empêcher qu’un changement considéré comme dangereux atteigne la production. Il ne désigne pas un résultat déjà mesuré sur l’ensemble des déploiements d’Empirik.
Une couche préalable plutôt qu’un substitut à l’observabilité
Les outils d’observabilité recueillent principalement les métriques, journaux et traces produits par des systèmes en fonctionnement. Ils servent à repérer une hausse des erreurs, une latence inhabituelle ou la propagation d’un défaut après l’arrivée d’un changement dans l’environnement d’exécution.
Empirik veut se placer plus tôt dans cette chronologie. Son entrée principale est une modification encore en attente ; sa sortie est une estimation de son impact pouvant mener à une autorisation, à l’ajout de contraintes ou à une revue humaine. Cette fonction est complémentaire de la surveillance : même correctement évalué, un changement peut produire un comportement imprévu que seule la télémétrie réelle révélera.
Le qualificatif « autonome » doit donc être lu avec cette limite. Certaines actions peuvent être autorisées automatiquement, mais l’entreprise cliente détermine le niveau d’autorité accordé au système et les changements les plus sensibles peuvent rester soumis à une décision humaine.
La réduction des incidents n’est pas encore documentée
Les informations publiées décrivent l’architecture promise et nomment quelques environnements de production, sans fournir de protocole d’évaluation ni de comparaison avant-après. L’analyse de Tech Times constate l’absence de résultats publics sur la précision des évaluations, les faux positifs et les lacunes de couverture dans les environnements partiellement instrumentés.
Ces mesures détermineront la valeur opérationnelle du produit. Un système trop permissif laisserait passer des changements dangereux ; un système trop prudent multiplierait les escalades et déplacerait simplement la file d’attente vers les équipes SRE. La qualité dépendra aussi de la capacité du modèle à maintenir ses relations à jour dans des infrastructures hétérogènes et éphémères.
L’état vérifiable de l’histoire est donc précis : Empirik dispose de plus de 21 millions de dollars, opère comme société indépendante et propose un contrôle des changements en amont des alertes. Il manque encore des résultats comparables sur les incidents évités, la précision des décisions, la proportion d’opérations autorisées automatiquement et les performances obtenues dans des environnements clairement définis.
À lire aussi:
Abonnez-vous à notre newsletter
Recevez directement les dernières actualités sur le Web3, l’IA et les cryptomonnaies.