Combien coûte vraiment une minute d’indisponibilité quand un paiement refuse de passer, qu’une application métier se fige ou qu’un tableau de bord client reste blanc ? Dans les entreprises numériques, la question n’est plus théorique. Elle revient à chaque déploiement, chaque mise à jour de configuration, chaque migration cloud. Une startup incubée par Sequoia, Empirik, vient de se présenter au marché avec une promesse nette : ne plus seulement observer les pannes, mais les anticiper avant qu’elles n’éclatent. Selon un reportage de TechCrunch, la jeune pousse sort de l’incubation avec 21 millions de dollars de financement d’amorçage et une ambition claire pour les équipes d’infrastructure.
Le timing n’est pas anodin. L’IA accélère la production de code. Les environnements se complexifient. Les dépendances se multiplient. Les équipes SRE et DevOps, déjà saturées d’alertes, doivent absorber un rythme de changement plus élevé que jamais. Empirik parie que l’intelligence artificielle peut jouer, pour l’infrastructure, le rôle que des outils comme Cursor ou Claude Code ont commencé à jouer pour le développement logiciel : automatiser une partie du travail répétitif afin de laisser les humains se concentrer sur ce qui crée vraiment de la valeur.
Une idée née chez Sequoia, pas dans un garage
L’histoire d’Empirik ne commence pas par un hackathon étudiant. Elle démarre dans les coulisses d’un fonds parmi les plus influents de la Silicon Valley. Avant de rejoindre Sequoia Capital en 2020 comme chief digital and information officer, Avon Puri a passé plus de dix ans à piloter l’infrastructure chez Rubrik et VMware. Il connaît donc, de l’intérieur, le coût réel d’un incident mal anticipé : nuits blanches, war rooms, communication de crise, et parfois perte de confiance client.
Il y a trois ans, alors que les grands modèles de langage commençaient à montrer une vraie capacité de raisonnement, Puri et un autre responsable IT de Sequoia, Sudheer Dhurjati, ont formulé une hypothèse simple. Si l’IA savait déjà lire du code, résumer des logs et proposer des correctifs, pourquoi ne pourrait-elle pas cartographier l’effet d’un changement sur un système entier ? Pourquoi rester dans une logique réactive alors que les signaux existent souvent avant la panne ?
Cette intuition a donné naissance à un produit capable de suivre les modifications et d’en déduire les répercussions en cascade. Sequoia a vu dans cette approche un nouveau type d’outil d’observabilité, moins tourné vers le constat après coup que vers la prévention et la résolution. Après avoir incubé le projet en 2023, le fonds a recruté plus tôt cette année Kartik Chandrayana au poste de CEO. Ancien CPO de Quantum Metric et vice-président observabilité chez Salesforce, il arrive avec une double culture produit et fiabilité à grande échelle.
Le 1er septembre 2026, Empirik a officialisé son spin-out en société indépendante. Le tour d’amorçage de 21 millions de dollars réunit Sequoia, Canapi et Alumni Ventures. Pour un marché aussi mature que celui du monitoring, ce n’est pas un chèque anodin : c’est un signal que certains investisseurs croient encore à une catégorie nouvelle, et non à un énième tableau de métriques.
Le vrai problème n’est pas le monitoring, c’est le changement
Les entreprises dépensent déjà des fortunes pour « garder les systèmes allumés ». Dashboards, APM, logs centralisés, tracing distribué, plateformes d’alerting : l’offre est pléthorique. Pourtant, les incidents continuent. Pourquoi ? Parce que la plupart des outils comprennent mal les dépendances complexes. Ils voient un symptôme. Ils voient une métrique qui dérape. Ils voient rarement la chaîne causale qui relie un petit changement anodin à une avalanche quelques heures plus tard.
There has always been a lot of money spent in keeping systems up and running.
– Bogomil Balkansky, partenaire chez Sequoia, cité par TechCrunch
Selon Bogomil Balkansky, partenaire de Sequoia, Empirik serait l’un des premiers outils vraiment dédiés au suivi des changements dans des environnements massifs. L’image qu’il retient est celle d’un « traffic cop » autonome : il laisse passer les modifications à faible risque, pose des garde-fous sur les plus sensibles, et envoie vers une revue humaine celles qui menacent vraiment la stabilité.
Cette métaphore du policier de la circulation est utile. Dans une ville, on n’arrête pas toutes les voitures. On régule les flux. On isole les carrefours dangereux. On laisse circuler le reste. L’infrastructure moderne ressemble de plus en plus à cette ville : microservices, files d’attente, caches, bases, réseaux, feature flags, pipelines CI/CD, configurations Kubernetes, secrets, politiques IAM. Un seul commit peut toucher dix services. Une seule variable d’environnement peut casser un contrat d’API.
Empirik se positionne donc moins comme un concurrent frontal des suites d’observabilité historiques que comme une couche de jugement sur le changement. Le produit ne promet pas seulement de dire « quelque chose cloche ». Il vise à dire « cette modification, dans ce contexte, avec ces dépendances, a une probabilité élevée de provoquer tel type d’effet ».
Ce que le produit cherche à automatiser concrètement
Derrière le discours marketing, le cœur fonctionnel reste assez lisible. Empirik observe les évolutions du système. Il infère les répercussions possibles. Il classe le risque. Il autorise, bride ou escalade. En d’autres termes, il tente de jouer le rôle d’un ingénieur d’infrastructure autonome pour une partie du quotidien opérationnel.
Pour les équipes DevOps et SRE débordées, l’intérêt n’est pas de remplacer l’expertise humaine. Il est de lui rendre du temps. Le troubleshooting de routine, les allers-retours entre tickets, runbooks et dashboards, les vérifications de cohérence après un déploiement : autant de tâches qui saturent les agendas sans forcément faire avancer l’architecture.
Depuis son lancement plus tôt dans l’année, la startup affirme déjà compter des clients allant de jeunes pousses à plusieurs acteurs du Fortune 500, parmi lesquels S&P Global, Guardant Health et un grand groupe de produits de grande consommation. Cette mixité est stratégique. Elle suggère que le besoin n’est pas réservé aux hyperscalers. Une scale-up en hypercroissance, un laboratoire de santé, une entreprise industrielle digitalisée : tous subissent la même loi. Plus le logiciel va vite, plus l’infrastructure doit absorber le choc.
Kartik Chandrayana le résume ainsi : à mesure que l’IA accélère le développement, les outils qui aident les ingénieurs d’infrastructure à suivre le rythme des changements deviennent indispensables. La formule qu’il avance est volontairement ambitieuse.
What agentic AI did for software, Empirik wants to do for infrastructure engineering.
– Kartik Chandrayana, CEO d’Empirik
Pourquoi cette thèse parle aux fondateurs et aux CMO autant qu’aux SRE
On pourrait croire qu’un outil de prévention d’incidents n’intéresse que les DSI. Ce serait une erreur de lecture. Dans une entreprise product-led, une panne n’est jamais « seulement technique ». Elle est un événement de marque. Elle interrompt un funnel. Elle casse une campagne. Elle fait exploser le volume du support. Elle alimente les commentaires négatifs. Elle peut même devenir un sujet de communication de crise si le service est grand public.
Les équipes marketing et croissance ont donc un intérêt direct à la fiabilité. Un lancement produit raté à cause d’une bascule de feature flag mal évaluée n’est pas un détail d’ingénierie. C’est un manque à gagner. De la même façon, une marketplace, une fintech ou une plateforme SaaS B2B qui promet un SLA élevé vend autant de la confiance que de la fonctionnalité. Empirik s’inscrit dans cette économie de la confiance.
Pour les startups, le sujet est encore plus vif. On pousse des releases plusieurs fois par jour. On expérimente. On scale trop tôt ou trop vite. On empile des services managés. On hérite de dettes invisibles. Dans ce contexte, un outil qui classe le risque d’un changement avant qu’il ne parte en production ressemble moins à un luxe qu’à une assurance de croissance.
Les investisseurs, eux, voient un marché adjacent à l’observabilité, déjà très financé, mais encore mal couvert sur un angle précis : la gouvernance intelligente du changement. Ce n’est pas le même problème que de collecter des traces. C’est le problème de décider, en temps réel, ce qui peut passer et ce qui doit être ralenti.
De l’observabilité classique à une couche agentique
L’observabilité traditionnelle répond à trois questions : que se passe-t-il, où, et depuis quand ? Les meilleures plateformes y ajoutent le « pourquoi » grâce à la corrélation de signaux. Empirik veut glisser vers une quatrième question, plus opérationnelle : que faut-il autoriser maintenant ?
C’est là que le mot agentic entre en scène. Un agent n’est pas un simple classificateur. Il observe, planifie, agit dans un périmètre, puis rend compte. Dans l’infrastructure, cela peut signifier valider un déploiement à bas risque, bloquer une configuration incompatible, ouvrir un ticket enrichi, proposer un plan de rollback, ou demander une validation à un humain pour un changement à fort blast radius.
Cette bascule change la nature du logiciel vendu. On ne monétise plus seulement des téraoctets de logs. On monétise une capacité de décision. C’est plus difficile à construire, car il faut un modèle de dépendances fiable, une compréhension des historiques d’incidents, et une discipline de faux positifs. Un outil trop prudent bloque l’innovation. Un outil trop permissif n’apporte rien. Toute la valeur se joue dans ce calibrage.
On comprend dès lors pourquoi Sequoia insiste sur le caractère complémentaire, et non substitutif, du produit. Balkansky situe Empirik dans une catégorie encore peu encombrée, en superposition d’autres plateformes d’AI SRE comme Resolve ou Traversal, cette dernière étant elle aussi liée à Sequoia. Autrement dit : le fonds ne raconte pas une guerre d’éviction. Il raconte une pile qui s’épaissit.
Ce que les 21 millions de dollars disent du marché
Un seed à 21 millions n’est plus un seed « classique ». Il ressemble à un ticket de conviction. Il finance à la fois le recrutement d’ingénieurs spécialisés, la construction d’intégrations, la preuve de valeur chez des grands comptes, et une narration de catégorie. Canapi, souvent associé aux thèses fintech et infrastructure financière, et Alumni Ventures élargissent le tour au-delà du seul réseau Sequoia.
Le message envoyé au marché est double. Premier message : l’IA appliquée aux opérations n’est plus un laboratoire. Elle devient un produit packagé, avec CEO, clients Fortune 500 et discours commercial. Second message : le goulot d’étranglement de l’ère agentique n’est pas seulement la génération de code. C’est la capacité des systèmes à encaisser ce code sans se rompre.
On peut le formuler autrement. Si chaque développeur produit davantage de changements grâce à l’IA, la surface d’incident augmente, sauf si une autre IA absorbe une partie du risque. Empirik vend précisément cette contrepartie. C’est une thèse d’équilibre, presque physique : à toute accélération du build doit répondre une accélération du control plane.
Les clients déjà cités dessinent un usage transverse
S&P Global évolue dans la donnée financière, où la disponibilité n’est pas un confort mais une exigence de marché. Guardant Health opère dans la santé, un univers où l’erreur opérationnelle a des implications réglementaires et humaines. Un grand CPG, lui, vit des pics saisonniers, des campagnes nationales et des chaînes logistiques numériques de plus en plus exposées. Trois univers, trois contraintes, un même besoin : comprendre l’effet d’un changement avant qu’il ne parte en production.
Cette diversité aide Empirik à éviter le piège du cas d’usage unique. Un outil qui ne marche que pour les scale-ups cloud natives aurait un plafond. Un outil qui ne parle qu’aux banques aurait un cycle de vente trop long. En mêlant startups et grands groupes, la société teste à la fois la vitesse d’adoption et la robustesse en environnement réglementé.
Pour un lecteur business, le signal le plus intéressant n’est pas la liste de logos. C’est le fait que le produit soit déjà en production assez tôt après le lancement. Dans l’infrastructure d’entreprise, les cycles d’évaluation sont longs. Avoir des références aussi vite suggère soit un pain point très aigu, soit un réseau d’introduction particulièrement efficace — les deux étant compatibles quand on sort d’un incubateur Sequoia.
Ce que cela change dans le quotidien d’une équipe SRE
Imaginons une équipe de quinze personnes responsable d’une plateforme utilisée par des millions d’utilisateurs. Chaque semaine, des centaines de changements transitent : images conteneur, règles de routage, quotas, schémas de base, politiques de cache, versions de librairies. L’humain ne peut pas tout relire avec la même intensité. Il priorise. Il rate des détails. Il apprend parfois trop tard.
Un système qui estime le rayon d’explosion d’un changement permet de réallouer l’attention. Les revues humaines se concentrent sur les modifications réellement dangereuses. Les autres avancent. Le temps de mean time to detect peut baisser, mais surtout le mean time to prevent — une métrique encore peu standardisée, et pourtant plus intéressante.
Cela implique aussi un nouveau contrat de confiance. L’équipe doit accepter qu’un modèle tranche une partie des décisions. Elle doit pouvoir auditer ces décisions. Elle doit pouvoir corriger le jugement de l’outil. Sans cette boucle, l’autonomie devient de l’opacité. Or, en infrastructure, l’opacité est précisément ce que l’on cherche à réduire.
Les organisations les plus matures poseront donc des questions précises : d’où viennent les graphes de dépendances ? Comment le modèle apprend-il des incidents passés ? Quelle est la politique en cas de désaccord entre l’outil et l’ingénieur de garde ? Qui est responsable si un changement « autorisé » casse la production ? Ces questions ne sont pas des détails juridiques. Elles détermineront l’adoption réelle.
Une catégorie encore ouverte, donc disputée demain
Balkansky affirme qu’Empirik est, pour l’instant, dans une catégorie à part. C’est le discours naturel d’un investisseur qui vient de mener un tour. Il n’est pas absurde pour autant. Beaucoup d’acteurs d’AIOps promettent la corrélation d’alertes, le résumé d’incidents, parfois la remédiation. Moins nombreux sont ceux qui placent le changement au centre du produit, comme objet premier à gouverner.
La concurrence arrivera néanmoins. Les grands éditeurs d’observabilité peuvent ajouter une couche de risk scoring. Les plateformes CI/CD peuvent enrichir leurs gates. Les acteurs d’AI SRE peuvent remonter plus haut dans le cycle, du run vers le change. Les cloud providers peuvent intégrer des politiques plus intelligentes dans leurs consoles. Empirik a donc une fenêtre, pas une rente.
Sa meilleure défense sera empirique, au sens propre. Il lui faudra démontrer, chiffres à l’appui, une baisse d’incidents liés au change, une réduction du toil, une accélération des déploiements sûrs. Sans ces preuves, le récit « traffic cop autonome » restera une métaphore élégante. Avec ces preuves, il pourra prétendre à un budget spécifique, distinct du monitoring historique.
Ce que les équipes produit et marketing devraient retenir
Si vous construisez un SaaS, un marketplace ou une app à fort trafic, trois leçons se dégagent de cette annonce relayée notamment par TechCrunch.
Première leçon : la vitesse de delivery sans gouvernance du risque n’est plus un avantage compétitif durable. C’est une dette qui explose au plus mauvais moment, souvent pendant une campagne, une levée ou un pic d’usage.
Deuxième leçon : l’IA générative a créé un déséquilibre. Elle a d’abord dopé ceux qui écrivent du logiciel. La vague suivante profite à ceux qui font tenir ce logiciel. Les budgets vont suivre cette bascule. Les discours de vente aussi.
Troisième leçon : la fiabilité devient un argument de positionnement. Dire « nous déployons plus vite » ne suffit plus. Dire « nous déployons plus vite sans casser l’expérience client » est plus fort, plus différenciant, plus aligné avec ce que paient réellement les entreprises.
Les points concrets à surveiller dans les prochains mois
Pour juger si Empirik tient sa promesse, quelques indicateurs vaudront mieux que les communiqués.
- La profondeur des intégrations avec les outillets déjà en place : CI/CD, Kubernetes, cloud providers, ITSM, observabilité.
- La qualité du graphe de dépendances sur des architectures réelles, pas seulement sur des démos propres.
- Le taux de faux positifs, car un garde-fou trop bruyant est contourné.
- La capacité à expliquer une décision en langage clair à un ingénieur de garde fatigué à 3 heures du matin.
- Les preuves chiffrées chez les premiers grands comptes, au-delà des logos.
- La frontière exacte avec les plateformes d’AI SRE déjà financées.
Ces critères sont exigeants. Ils le sont à dessein. Dans l’infrastructure, on n’achète pas une vision. On achète une réduction de risque mesurable. Les fondateurs le savent. Les SRE encore plus.
Incubation Sequoia : avantage de réseau, exigence de preuve
Sortir d’un incubateur Sequoia n’est pas un détail de storytelling. Cela donne accès à des introductions, à une légitimité immédiate, à un vivier de premiers clients et de talents. Cela crée aussi une attente plus haute. Le marché observe ces spin-outs avec une sévérité particulière : si le fonds le plus visible de la Valley soutient une nouvelle catégorie, le produit doit vite cesser de ressembler à une thèse interne.
Le recrutement de Kartik Chandrayana s’inscrit dans cette logique. Passer d’une idée née chez des leaders IT du fonds à une société indépendante dirigée par un profil produit issu de l’observabilité et de l’expérience digitale, c’est admettre qu’il ne suffit pas d’avoir raison sur le diagnostic. Encore faut-il packager, vendre, onboarder, fidéliser.
Avon Puri et Sudheer Dhurjati apportent la cicatrice opérationnelle. Chandrayana apporte le réflexe de mise en marché. Balkansky apporte le cadre d’investissement. Cette triangulation est classique dans les meilleures sorties d’incubation. Elle n’élimine pas le risque d’exécution. Elle le rend simplement plus lisible.
L’infrastructure comme prochain grand terrain de l’IA agentique
Depuis deux ans, le grand public a surtout vu l’IA générative écrire des textes, des images, du code. Les entreprises, elles, commencent à chercher des agents capables d’agir dans des systèmes à conséquences. L’infrastructure est un terrain idéal et dangereux à la fois. Idéal, parce que les données d’état existent déjà : métriques, événements de change, tickets, postmortems. Dangereux, parce qu’une mauvaise action autonome peut coûter très cher.
Empirik choisit une voie intermédiaire plus vendable que l’auto-remédiation totale. Le « traffic cop » n’éteint pas lui-même tous les feux. Il filtre le trafic. Il réduit le nombre de collisions. Il réserve l’intervention humaine aux carrefours critiques. Cette architecture de gouvernance a plus de chances d’entrer dans une grande entreprise qu’un agent laissé libre de patcher la production à minuit.
Pour les lecteurs qui suivent la tech, le business et la communication digitale, c’est aussi une leçon de narration. Empirik ne se vend pas comme « encore un outil de logs ». Elle se vend comme l’équivalent infrastructure de la révolution copilot côté développeurs. Cette analogie est puissante. Elle est aussi risquée, car elle crée une attente de gain de productivité immédiat. Le produit devra la justifier.
Comment relire cette annonce si vous construisez une stack moderne
Vous n’avez pas besoin d’acheter Empirik demain matin pour tirer parti de l’information. Vous pouvez déjà auditer votre propre chaîne de changement. Qui autorise quoi ? Quels déploiements partent sans revue ? Quels services ont un blast radius mal documenté ? Quels runbooks sont obsolètes ? Quelle part des incidents des douze derniers mois vient d’un changement « mineur » mal compris ?
Ces questions valent pour une startup de vingt personnes comme pour un groupe du CAC ou du Fortune 500. Elles valent aussi pour les équipes growth qui poussent des expériences chaque semaine. Un test A/B mal isolé, une bascule de configuration marketing trop large, une intégration tierce mal versionnée : le risque n’habite pas seulement le socle technique. Il habite tout ce qui modifie l’état du système.
C’est pourquoi le sujet dépasse les SRE. Il concerne la manière dont une organisation accepte d’aller vite. La culture « ship it » a eu son époque. L’époque suivante ressemble davantage à « ship it with a modeled blast radius ». Moins glamour. Beaucoup plus adulte.
Les limites qu’il faut nommer sans détour
Un article utile ne se contente pas de relayer une levée. Empirik devra prouver qu’un modèle peut vraiment inférer des effets de bord dans des systèmes imparfaitement documentés. Or la plupart des entreprises n’ont pas un inventaire propre. Les CMDB sont incomplètes. Les schémas d’architecture datent. Les dépendances cachées vivent dans des cron jobs oubliés et des comptes de service trop permissifs.
Si le produit a besoin d’un jardin parfaitement entretenu pour fonctionner, son marché se rétrécit. S’il sait au contraire découvrir des dépendances à partir du comportement réel, sa valeur explose. Toute la bataille technique se joue probablement là, plus que dans l’interface.
Autre limite : le facteur humain. Un outil qui flag trop souvent devient du bruit. Un outil qui laisse trop passer devient invisible jusqu’à la catastrophe. Le calibrage devra être local, par équipe, par criticité métier, par environnement. La même politique ne peut pas s’appliquer à un sandbox et à un système de compensation de paiements.
Enfin, la catégorie « à part » durera peu. Dès qu’un usage se confirme, les plateformes installées copient, partenarient ou rachètent. Empirik a l’avantage du focus. Elle n’a pas encore l’avantage de l’inertie installée. Les 21 millions servent précisément à transformer le focus en base installée avant que la fenêtre ne se referme.
Ce que cette histoire raconte de 2026
Nous ne sommes plus dans la phase où il suffisait d’ajouter « powered by AI » à une page d’accueil. Les projets qui lèvent désormais racontent un goulot précis. Ici, le goulot est limpide : l’IA fait coder plus vite que les organisations ne savent opérer. Empirik se glisse dans cet écart.
On y retrouve aussi une constante de la Valley. Un problème vécu de l’intérieur par des opérateurs expérimentés. Un fonds qui convertit une douleur interne en société. Un CEO produit amené pour industrialiser. Des clients logos pour crédibiliser. Une analogie grand public — Cursor, Claude Code — pour rendre le pitch mémorable. La mécanique est connue. Elle n’empêche pas le produit d’être utile.
Pour les lecteurs qui travaillent dans la tech, le marketing ou l’investissement, la bonne lecture n’est donc pas « encore une startup d’observabilité ». La bonne lecture est : la fiabilité redevient un terrain d’innovation, parce que la génération de logiciel a basculé dans une autre vitesse. Ceux qui sauront vendre de la prévention, et pas seulement du diagnostic, auront une place dans les budgets 2026 et 2027.
En pratique, que faire de cette information dès cette semaine
Si vous dirigez une équipe technique, cartographiez vos cinq derniers incidents majeurs et isolez ceux qui venaient d’un changement sous-estimé. Si le ratio est élevé, vous avez déjà le business case d’une approche type Empirik, que vous l’achetiez ou que vous la construisiez en interne.
Si vous dirigez le produit, reliez vos roadmaps de delivery à un indicateur de risque de change. Un velocity qui grimpe pendant que le taux d’incidents liés aux releases grimpe aussi n’est pas une victoire. C’est un transfert de dette vers le support et la marque.
Si vous dirigez la croissance ou la communication, interrogez-vous sur la manière dont une interruption serait racontée demain. Avez-vous un langage commun avec l’infra ? Savez-vous quels parcours clients sont réellement critiques ? La prévention des pannes est aussi un sujet de discours, pas seulement de tickets PagerDuty.
Et si vous observez le marché des startups, gardez Empirik dans un coin de veille. Pas parce que toute thèse Sequoia devient automatiquement un standard. Parce que le problème qu’elle attaque est structurel. Tant que l’IA accélérera le build, quelqu’un devra freiner intelligemment le blast radius. Qu’il s’agisse d’Empirik ou d’un successeur, cette fonction trouvera un acheteur.
Une conclusion utile, sans slogan creux
Empirik arrive avec un financement solide, des fondateurs qui ont opéré de vrais systèmes, un CEO issu de l’observabilité, des clients déjà nommés et une analogie facile à retenir. L’annonce reprise par TechCrunch a le mérite de formuler clairement un basculement : passer du constat de la panne à la régulation du changement qui la précède.
Le marché n’a pas besoin d’un énième écran rouge. Il a besoin d’un jugement plus fin sur ce qui peut circuler dans la ville numérique qu’est devenue une plateforme moderne. Si Empirik parvient à tenir ce rôle de régulateur sans étouffer le trafic, elle n’aura pas seulement levé 21 millions de dollars. Elle aura donné un nom productisé à une fonction que toutes les organisations digitalisées cherchent encore, souvent trop tard, après l’incident.
Le prochain chapitre ne se jouera pas dans un communiqué. Il se jouera dans les postmortems que les clients n’auront pas eu à écrire. C’est, au fond, la seule métrique qui compte pour un outil qui promet de prédire les pannes avant qu’elles n’arrivent.






