Kristin Isaac, PDG et co-fondatrice de Strudel – Série d’entretiens

Kristin Isaac, PDG et co-fondatrice de Strudel, est une veterane du leadership technologique d’entreprise qui a occupé des postes seniors chez LinkedIn, Udemy, ESPN et Disney avant de lancer Strudel. Elle se concentre désormais sur la résolution de l’un des principaux points de friction dans les organisations logicielles : l’écart entre le support client et l’ingénierie. Chez Strudel, elle construit une plateforme alimentée par l’IA qui aide les équipes de support technique à résoudre les problèmes complexes plus rapidement en reliant les demandes de support directement à l’intelligence d’ingénierie. Son expérience dans la mise à l’échelle des équipes, la création de stratégies de lancement sur le marché et la stimulation de la croissance dans les organisations mondiales a contribué à façonner la traction précoce et solide de Strudel sur le marché de l’IA d’entreprise et des outils de développement.

Strudel est une plateforme d’IA conçue pour automatiser le support technique avancé en analysant les journaux, les données de production, les référentiels de code et l’historique des support pour identifier les causes profondes et recommander des solutions. Son objectif est de réduire le temps et les efforts d’ingénierie nécessaires pour résoudre les cas de support difficiles, en particulier les escalades qui consomment généralement des ressources techniques seniors. En reliant le support directement aux problèmes techniques sous-jacents, Strudel se positionne comme un outil capable de rendre les opérations de support d’entreprise plus rapides, plus efficaces et plus évolutives.

Vous avez occupé des postes de leadership chez des organisations comme LinkedIn, Udemy et Disney avant de fonder Strudel en 2025. Quelles expériences dans ces rôles vous ont finalement convaincu que les équipes d’ingénierie avaient besoin d’une nouvelle sorte de plateforme d’intelligence d’ingénierie alimentée par l’IA, et comment cette compréhension a façonné la création de Strudel ?

Chaque entreprise où j’ai travaillé avait une version différente du même problème. Chez Disney, les enjeux étaient énormes – si une plateforme de streaming tombait pendant un lancement important, ce n’était pas seulement un impact sur les revenus, c’était un moment de marque. Chez LinkedIn, l’échelle était impitoyable. Il y avait des milliers de services générant du bruit, et même les meilleures équipes luttaient pour suivre. Chez Udemy, j’ai vu une équipe lean accomplir des choses héroïques avec un outillage limité.

Ce qui relie les trois, ainsi que l’expérience de mes co-fondateurs, Shai Rubin et Brian Kaufman, en tant que leaders d’équipes d’ingénierie, c’est que les ingénieurs passaient plus de temps à reconstituer le contexte qu’à résoudre réellement les problèmes. Quelqu’un reçoit une alerte à 2 heures du matin, et avant même de commencer à diagnostiquer, il fouille dans les threads Slack, les tableaux de bord, les tickets Jira, les journaux de déploiement – juste pour comprendre ce qui a changé et quand. Ils jouent essentiellement les détectives avant de pouvoir faire leur véritable travail. C’est un gaspillage de personnes incroyablement talentueuses.

Je me suis souvent demandé : il doit y avoir une façon plus intelligente de mettre en surface ce qui compte vraiment, quand cela compte. C’est vraiment la graine de Strudel.

De nombreuses entreprises mesurent l’impact financier des temps d’arrêt en termes de pertes de revenus ou de pénalités de SLA. Selon votre expérience, quels sont certains des coûts moins visibles des temps d’arrêt que les organisations sous-estiment systématiquement ?

Le chiffre des revenus figure dans le rapport du conseil d’administration, mais l’impact immédiat sur les revenus n’est qu’une fraction de ce que le temps d’arrêt coûte réellement. Ceux que j’ai vus les organisations sous-estimer systématiquement se divisent en quelques catégories.

La première est la confiance des clients. Les pénalités de SLA sont une construction juridique – elles ne capturent pas le client qui se désabonne discrètement ou le prospect d’entreprise qui a vu votre page de statut au mauvais moment et a choisi un concurrent. Ce préjudice est lent, invisible et permanent d’une manière que tout simplement un chèque de remboursement ne l’est pas.

Le deuxième est l’attrition et l’épuisement des ingénieurs. La fatigue liée aux appels est réelle. Lorsque vos meilleurs ingénieurs sont régulièrement impliqués dans des incidents à haute pression – en particulier ceux qui auraient pu être prévenus – ils commencent à se demander si c’est vraiment l’endroit où ils devraient construire leur carrière. Remplacer un ingénieur senior coûte entre une et deux fois son salaire annuel une fois que vous prenez en compte le recrutement, la formation et les connaissances institutionnelles perdues. Personne ne le met dans le post-mortem.

Le troisième est le coût d’opportunité. Chaque heure qu’une équipe d’ingénierie passe à combattre les incendies est une heure qui n’est pas passée à construire un produit. C’est difficile à mettre sur une feuille de calcul, mais cumulé sur des mois, cela détruit tranquillement votre feuille de route.

Les ingénieurs sont souvent détournés de la construction de nouvelles fonctionnalités pour répondre aux incidents de production. Comment ce feu de forêt constant affecte-t-il l’innovation du produit et les feuilles de route de développement à long terme ?

Cela crée une taxe sur la capacité de l’équipe d’ingénierie à construire. Chaque équipe a une quantité finie de bande passante, et lorsque une partie importante de celle-ci est constamment redirigée vers les incidents, l’effet cumulé sur le développement de produits est grave. Les engagements de feuille de route sont manqués. La dette technique ne se paie pas. Les fonctionnalités sont expédiées avec moins de rigueur parce qu’il y a une pression pour rattraper le temps perdu.

Ce qui est particulièrement préjudiciable, c’est l’imprévisibilité. Une équipe peut planifier son sprint avec de bonnes intentions, puis un incident majeur éclate un mardi et tout le reste devient secondaire. Ce type d’imprévisibilité durable rend presque impossible la construction d’une culture de travail approfondi – qui est finalement ce qui conduit aux meilleurs résultats d’ingénierie.

Cela crée également un cycle auto-renforçant. Les investissements différés signifient plus d’incidents, ce qui signifie plus de lutte contre les incendies, ce qui signifie encore moins de temps pour investir dans les problèmes sous-jacents. Chez Strudel, une grande partie de ce que nous construisons est spécifiquement pour les équipes SRE qui vivent cela tous les jours.

Strudel relie les données de support client, les journaux, les systèmes de production et les référentiels de code pour identifier les causes profondes plus rapidement. Comment l’IA rassemble-t-elle ces différents signaux techniques d’une manière que les outils de surveillance traditionnels ne peuvent pas ?

Les outils de surveillance traditionnels sont fondamentalement des systèmes d’alerte. Ils sont excellents pour vous dire que quelque chose a dépassé un seuil – une augmentation de latence, un taux d’erreur en hausse, un pod en panne. Ce qu’ils ne peuvent pas faire, c’est raisonner à travers les domaines.

Ils ne savent pas que la hausse du taux d’erreur dans votre service de paiement s’est produite quatre minutes après un déploiement vers une dépendance, et qu’un ticket de support mentionnant les échecs de paiement est arrivé à peu près à la même heure, et que la dernière fois que ce modèle est apparu dans vos journaux, c’était il y a six mois, lors d’une migration de base de données.

C’est cette corrélation interdomaine que permet l’IA. Nous pouvons traiter un ticket Zendesk, un commit GitHub, une trace Datadog (DDOG ) et un journal CloudWatch comme faisant partie d’une histoire unifiée plutôt que des points de données isolés. L’IA met en surface non seulement ce qui est cassé, mais la raison probable et l’endroit – et elle le fonde sur des preuves que l’ingénieur humain peut réellement vérifier et agir. Nous ne demandons pas aux équipes de faire confiance à une boîte noire. Nous leur donnons une hypothèse bien raisonnée et un avantage.

Vous décrivez Strudel comme apportant « l’intelligence d’ingénierie ». Qu’est-ce que ce concept signifie dans la pratique, et comment diffère-t-il des plates-formes d’observabilité ou d’AIOps conventionnelles ?

Kristin : L’observabilité est fondamentalement à propos de l’instrumentation et de la visibilité – s’assurer que la télémétrie est là et que les équipes peuvent la requêter. L’AIOps, dans la plupart de ses implémentations actuelles, est à propos de la réduction du bruit d’alerte via la corrélation et la détection d’anomalies basées sur le ML. Les deux sont réellement précieuses, et nous nous intégrons à elles.

Mais l’intelligence d’ingénierie est une couche au-dessus. Nous prenons ce que fait l’AIOps et nous l’élargissons. Là où l’AIOps vous dit que quelque chose ne va pas, l’intelligence d’ingénierie aide à comprendre pourquoi cela ne va pas, d’où cela vient et quoi faire à ce sujet – en tirant des signaux de l’ensemble de votre pile, y compris des sources que les outils AIOps traditionnels ne regardent même pas, comme les tickets de support client ou les modifications de code. L’objectif n’est pas seulement de réduire le bruit. C’est de donner à votre équipe une image complète et actionnable afin qu’ils puissent résoudre le problème plus rapidement et revenir à la construction.

C’est la différence entre un détecteur de fumée et un enquêteur d’incendie. L’observabilité et l’AIOps sont le détecteur de fumée – essentiel, mais ils s’arrêtent à l’alarme. L’intelligence d’ingénierie est ce qui vient après : voici ce qui s’est passé, voici pourquoi, voici d’où cela a commencé.

Les agents d’IA sont de plus en plus déployés pour automatiser des flux de travail techniques complexes. Quel rôle pensez-vous que les agents d’IA joueront dans le diagnostic et la résolution des incidents logiciels au cours des cinq prochaines années ?

Je pense que la question la plus intéressante n’est pas ce que les agents feront – c’est ce que les ingénieurs arrêteront de faire. Les meilleurs ingénieurs avec qui j’ai travaillé ne sont pas entrés dans ce domaine pour passer leurs nuits à trier des alertes ou à fouiller dans les journaux pour une modification de configuration qu’un quelqu’un a faite un vendredi après-midi. Ce n’est pas pour cela qu’ils sont devenus bons dans leur travail. Mais c’est exactement ce que leur temps est englouti.

Au cours des cinq prochaines années, je pense que les agents prennent en charge une grande partie de ce travail de routine – le travail de reconnaissance de modèles, d’assemblage de contexte, de triage qui est important mais ne nécessite pas que les talents d’ingénierie senior soient dépensés. Cela libère les gens pour se concentrer sur les problèmes complexes, les décisions architecturales, les choses qui nécessitent réellement un jugement humain.

Ce qui m’excite, c’est que ce n’est pas seulement un état futur – nous le voyons se dérouler dès maintenant, y compris chez Strudel. Notre feuille de route entière est orientée vers la suppression du travail administratif et de maintenance des plateaux d’ingénieurs. Et ce que nous constatons, honnêtement, c’est que cela change ce qui est possible pour une équipe. Vous pouvez construire plus, bouger plus vite et le faire avec moins de personnes – parce que les personnes que vous avez sont concentrées sur la stratégie et la complexité plutôt que sur le travail répétitif. Cela ressemble à un changement significatif dans la façon dont les équipes sont construites et structurées à l’avenir.

De nombreux temps d’arrêt proviennent de petits bogues ou de modifications de configuration qui passent inaperçus lors des tests. Comment les systèmes d’IA peuvent-ils identifier des modèles subtils dans le code, les journaux ou les signaux d’infrastructure suffisamment tôt pour prévenir les incidents majeurs ?

Un AI bien conçu a un avantage réel ici, et ce n’est pas qu’il est plus intelligent que vos ingénieurs – c’est qu’il n’oublie jamais et ne dort jamais. Un humain pourrait ne pas relier un modèle de journal subtil aujourd’hui à quelque chose qui s’est passé il y a six mois dans une partie complètement différente du système. L’IA peut. Elle surveille tout, tout le temps, et elle a une mémoire beaucoup plus longue et plus large que n’importe quel membre de votre équipe.

Cela étant dit, il y a aussi quelque chose que nous entendons beaucoup de la part des clients : la prévention n’est que aussi bonne que les données qui se trouvent en dessous. Si vos journaux sont incohérents, incomplets ou cloisonnés dans une douzaine d’outils qui ne parlent pas les uns aux autres, l’IA travaille avec une image fragmentée. Garbage in, garbage out – cela est toujours vrai. Nous passons beaucoup de temps avec les clients à les aider à réfléchir à la qualité des données et à l’instrumentation, car la meilleure IA du monde ne peut pas mettre en surface un signal qui n’a jamais été capturé en premier lieu.

Donc la réponse est les deux : oui, l’IA peut attraper les choses plus tôt et relier les points que les humains manqueraient. Mais les équipes qui tirent le plus de valeur de l’IA sont celles qui ont également fait le travail pour s’assurer que leurs données sont réellement dignes de raisonnement.

Les entreprises investissent souvent lourdement dans les outils de détection mais ont encore du mal à réduire le temps moyen de résolution. Quels sont les principaux obstacles qui empêchent les organisations de combler l’écart entre la détection d’incident et la résolution réelle de la cause profonde ?

La détection est en grande partie un problème résolu à ce stade. La plupart des équipes ont des alertes. Ils savent que quelque chose ne va pas. L’écart est tout ce qui se passe ensuite.

Lorsqu’un ingénieur reçoit une alerte, il ne se présente pas dans une situation claire avec tout le contexte pertinent assemblé. Il se présente dans un chaos. Il doit déterminer ce qui a changé, quand cela a changé, quel système cela a touché, s’il y a un impact client, s’il est lié à quelque chose qui s’est passé la semaine dernière. Il tire de Slack, des tableaux de bord, des journaux de déploiement, des tickets de support – faisant ce travail d’assemblage manuellement, sous pression, souvent en pleine nuit.

C’est l’assemblage du contexte qui est le goulet d’étranglement. Ce n’est pas que les ingénieurs et les équipes de support ne savent pas résoudre les problèmes – c’est qu’ils passent les premières 30 à 60 minutes de chaque incident à essayer de comprendre ce à quoi ils sont confrontés. C’est là que Strudel intervient. Notre thèse entière est que si vous pouvez donner à un ingénieur une image cohérente et étayée par des preuves de ce qui s’est passé et pourquoi – exactement quand il en a besoin – vous réduisez considérablement cet écart. Le travail de résolution est toujours le leur. Nous les amenant simplement à la ligne de départ beaucoup plus rapidement.

À mesure que les systèmes d’IA commencent à analyser les données de production, les codes sources et les journaux opérationnels, quels sont les considérations de gouvernance ou de sécurité que les équipes d’ingénierie devraient avoir à l’esprit lors du déploiement de ces outils ?

La chose à laquelle je tiens le plus ici, c’est ceci : les humains devraient toujours examiner le code qui va en production.

J’ai parlé à de nombreux ingénieurs à ce sujet, et une chose que j’entends constamment, c’est que l’IA écrit des bogues efficacement et de manière ingénieuse. Vraiment ingénieusement, en fait. D’une manière qui peut être vraiment difficile à détecter – même pour les ingénieurs seniors qui examinent soigneusement le code. Les bogues ne sont pas toujours évidents. Ils peuvent paraître parfaitement raisonnables à un coup d’œil.

Donc, à mesure que l’IA écrit plus de code qui se retrouve en production, je pense que nous allons voir plus de ces problèmes subtils et difficiles à détecter passer inaperçus – non parce que quelqu’un était négligent, mais parce que la nature des bogues générés par l’IA est différente. Plus difficile à détecter lors de l’examen. Plus difficile à détecter lors des tests.

Honnêtement ? C’est l’une des raisons pour lesquelles je pense que le cas de ce que fait Strudel ne fait que se renforcer avec le temps. Si plus de bogues se glissent en production, la capacité de les trouver et de les résoudre plus rapidement devient plus importante, et non moins importante. La question de gouvernance n’est pas seulement à propos des contrôles d’accès aux données et des autorisations – bien que ces choses comptent et que les équipes devraient y réfléchir attentivement. C’est aussi de garder les humains aux bons points de contrôle, en particulier autour de tout ce qui touche la production.

En regardant vers l’avenir, pensez-vous que le futur de l’ingénierie de la fiabilité se dirigera vers des infrastructures d’IA premières, où les systèmes autonomes surveillent, diagnostiquent et même réparent les problèmes avant que les humains en soient conscients ? Si oui, à quoi ressemble le flux de travail futur pour les ingénieurs ?

Je pense que nous allons dans cette direction, mais je suis pragmatique quant au calendrier. Des systèmes entièrement autonomes résolvant des incidents de production sans aucune prise de conscience humaine – cela n’est pas où nous sommes, et je ne pense pas que nous y serons dans les prochaines années. Et je pense que c’est bien.

Ce que je crois, c’est que la boucle se resserre et devient moins douloureuse. Le futur que j’apprécie n’est pas celui où les humains sont retirés de l’équation – c’est celui où les humains intégrés dans le processus passent leur temps sur les parties qui nécessitent réellement leur présence. Les appels de jugement. Les situations nouvelles. Un incident que vous n’avez jamais vu auparavant. L’IA gère la reconnaissance de modèles, l’assemblage de contexte, le triage de routine. Les ingénieurs gèrent les décisions.

Pour les ingénieurs eux-mêmes, je pense que cela ressemble à : moins de temps sur appel en pleine nuit pour des choses qui n’auraient pas dû les réveiller, et plus de temps à construire des systèmes qui ne cassent pas en premier lieu. Le feu de forêt ne disparaît pas entièrement. Mais il devient l’exception plutôt que l’état par défaut d’être un ingénieur dans une entreprise qui exécute des logiciels à grande échelle. C’est un avenir qui vaut la peine d’être construit.

Merci pour cette grande interview, les lecteurs qui souhaitent en savoir plus peuvent visiter Strudel.