Abby Kearns, PDG d’ActiveState – Série d’entretiens

Abby Kearns est la PDG d’ActiveState et une dirigeante technologique ayant plus de 25 ans d’expérience dans la construction et la mise à l’échelle d’organisations de logiciels d’entreprise. Elle a précédemment occupé le poste de CTO de Puppet, où elle a aidé à mener une transformation stratégique qui a abouti à l’acquisition de l’entreprise par Perforce Software. Plus tôt dans sa carrière, elle était PDG de la Cloud Foundry Foundation, guidant la croissance de l’un des plus grands écosystèmes de plateformes de cloud open source de l’industrie. Abby siège actuellement au conseil d’administration d’Akka (anciennement Lightbend). Elle est connue pour aider les entreprises à traduire les grands changements dans le cloud, les logiciels open source et l’IA en une stratégie de produit claire et en une croissance d’entreprise.

ActiveState est une société de logiciels canadienne fondée en 1997 qui fournit des outils et des plateformes d’entreprise pour la construction, la gestion et la sécurisation des logiciels open source. Son offre principale, la plateforme ActiveState, aide les équipes de développement, de DevOps et de sécurité à automatiser la gestion des dépendances, à détecter et à remédier aux vulnérabilités, et à créer des environnements de développement sécurisés et reproductibles sur plusieurs langages de programmation comme Python, Perl et Tcl. En fournissant des composants open source préconstruits et vérifiés et en les intégrant dans les flux de travail existants, ActiveState vise à réduire les risques de sécurité dans la chaîne d’approvisionnement logiciel tout en améliorant la productivité des développeurs et en accélérant la livraison des applications.

Vous avez passé votre carrière à l’intersection des logiciels open source, des plateformes cloud-native et de la transformation d’entreprise, de la direction de la Cloud Foundry Foundation à votre rôle de CTO chez Puppet. Qu’est-ce qui vous a amenée à prendre le rôle de PDG d’ActiveState, et quelle est votre vision pour l’entreprise dans cette prochaine phase de croissance ?

Le fil conducteur de ma carrière a été d’opérer à l’intersection de la communauté et de l’infrastructure au moment où l’industrie prend des décisions qui auront des conséquences pendant des années. Cloud Foundry était ce moment pour le cloud-native. Puppet était ce moment pour la gestion de la configuration et les premières étapes de ce que nous appelons maintenant DevSecOps. ActiveState est ce moment pour la gouvernance des logiciels open source.

Ce qui m’a attirée ici est un problème que j’ai vu se construire pendant longtemps. Chaque entreprise que j’ai rencontrée fonctionne sur des logiciels open source. La plupart d’entre elles ne peuvent pas dire avec confiance quels logiciels open source elles utilisent, s’ils ont été corrigés ou qui est responsable de la décision de les utiliser. L’écart entre la façon dont les logiciels open source sont devenus fondamentaux et la façon dont la plupart des organisations appliquent peu de rigueur pour les gérer est où le risque de l’industrie s’accumule. ActiveState a passé vingt ans à construire l’infrastructure pour combler cet écart. Mon travail est de m’assurer que le marché comprend pourquoi combler cet écart est urgent.

La vision pour cette prochaine phase est claire : ActiveState devient la réponse par défaut à la question de l’origine des logiciels open source d’entreprise. Pas un scanner. Pas un rapport. Une source fiable, vérifiée, constamment corrigée que les organisations peuvent désigner lorsqu’elles sont interrogées par les régulateurs, les conseils d’administration ou les intervenants en cas d’incident sur la façon dont elles ont géré leur chaîne d’approvisionnement logiciel.

ActiveState se positionne comme une couche critique pour sécuriser la chaîne d’approvisionnement logiciel à un moment où l’IA accélère la génération de code. Comment l’IA modifie-t-elle fondamentalement le profil de risque des logiciels open source ?

Le développement assisté par l’IA brise une hypothèse fondamentale sur laquelle toute la chaîne d’outils de gouvernance des logiciels open source a été construite : qu’un développeur a pris une décision délibérée d’inclure une dépendance.

Chaque mandat SBOM, chaque outil SCA, chaque flux de travail de gestion des vulnérabilités suppose qu’il y avait un humain dans la boucle qui a choisi de tirer cette bibliothèque. Lorsque l’IA génère du code, des dépendances arrivent en production que personne n’a sélectionnées, examinées ou, dans de nombreux cas, ne sait même qu’elles sont là. L’outillage de gouvernance recherche des décisions. L’IA prend des décisions de production qui contournent entièrement la décision.

Il y a une deuxième couche à cela. Les outils de codage qui ont conduit à l’adoption de l’IA, les repères de productivité, les enquêtes auprès des développeurs, les étoiles GitHub, aucun de ces cadres d’évaluation n’a inclus la sécurité comme mesure de premier ordre. L’industrie a optimisé la vitesse et la correction et a expédié l’infrastructure sans se demander si la sortie était sûre. Ce n’est pas une défaillance de l’outillage. C’est une défaillance de leadership dans la façon dont les décisions d’adoption ont été prises. Nous opérons maintenant à grande échelle sur une base qui n’a jamais été évaluée pour le risque qu’elle introduisait.

Vous avez déclaré que les logiciels open source non gérés deviennent une vulnérabilité majeure pour les entreprises. Pourquoi la gouvernance des logiciels open source est-elle maintenant élevée au niveau du conseil d’administration, et qu’est-ce que les dirigeants sous-estiment encore ?

Cela atteint le conseil d’administration parce que l’environnement réglementaire a changé la structure de responsabilité. L’Acte de résilience cybersécurité de l’UE, les exigences de divulgation de la SEC, les directives Secure by Design de la CISA : ces cadres déplacent la question de “Avez-vous un scanner ?” à “Pouvez-vous prouver que votre logiciel était sécurisé au point d’origine ?” Ce sont des questions très différentes, et la plupart des organisations ne peuvent pas répondre à la deuxième.

Ce que les dirigeants sous-estiment encore est que c’est un problème structurel, et non un problème de ressources. Les organisations que je vois répondre au risque des logiciels open source en ajoutant plus d’outils de scan ne résolvent pas le problème sous-jacent. Le scan détecte les problèmes après qu’ils sont entrés dans votre environnement.

Lorsque tout est signalé, rien n’est prioritaire, et le volume d’alertes devient sa propre dysfonctionnement opérationnel. Les organisations qui navigueront avec succès ne sont pas celles qui achètent plus d’outils. Ce sont celles qui changent la façon dont elles prennent des décisions sur les logiciels open source qui entrent dans leur environnement, et qui sont responsables de ces décisions.

<strong Avec les logiciels open source maintenant intégrés dans la plupart des piles logicielles d'entreprise, comment les organisations devraient-elles repenser les logiciels open source en tant qu'infrastructure plutôt que comme un simple moyen de développement ?

Le modèle mental que la plupart des organisations utilisent est obsolète depuis dix ans. Les logiciels open source ont commencé comme un moyen de développement. Les développeurs pouvaient tirer des bibliothèques, aller plus vite et éviter de réinventer les composants fondamentaux. Ce cadrage avait du sens lorsque les logiciels open source étaient optionnels et supplémentaires.

Ce n’est pas la réalité actuelle. Les logiciels open source sont la base des logiciels modernes. Quatre-vingt-seize pour cent des applications incluent des composants open source. Ce n’est pas une couche de convenance au-dessus de l’infrastructure propriétaire. C’est l’infrastructure. Et l’infrastructure doit être gérée comme de l’infrastructure, avec des politiques explicites sur ce qui entre dans l’environnement, une propriété définie pour la maintenance et la correction, et une responsabilité qui siège au bon niveau de l’organisation.

Les organisations qui sont en avance sur ce point ont fait un changement délibéré : la consommation de logiciels open source est une décision stratégique avec des conséquences de sécurité et financières, et non un réglage par défaut que les développeurs gèrent individuellement. Ce changement nécessite une politique, un processus opérationnel et une responsabilité exécutive claire. La plupart des organisations n’ont pas encore fait ce changement.

Vous avez dirigé des organisations à travers plusieurs vagues technologiques. Comment le changement actuel impulsé par l’IA se compare-t-il aux transitions précédentes comme le cloud et le DevOps en termes de vitesse et de perturbation ?

Le mouvement actuel impulsé par l’IA est très similaire aux changements technologiques précédents. Lorsque le cloud est apparu comme un modèle de livraison, les organisations qui l’ont traité comme un choix purement technologique ont fait des erreurs très différentes de celles qui ont reconnu qu’il s’agissait d’un changement architectural et opérationnel. Ceux qui ont échoué à faire la transition de gouvernance ont payé pour cela pendant des années en termes d’IT fantôme, de dépassements de coûts et de dette technique et de sécurité.

Ce qui est différent dans le changement actuel impulsé par l’IA est la vitesse et l’invisibilité. L’adoption du cloud était visible. Vous saviez lorsque votre organisation migrait des charges de travail de l’entreprise vers le cloud. Le DevOps était visible : les organisations réorganisaient les équipes, changeaient les pipelines de déploiement et réécrivaient les processus. Les outils de codage IA sont adoptés développeur par développeur, appel d’outils par appel d’outils, et le risque s’accumule dans la base de code avant que la plupart des organisations n’aient enregistré qu’une décision de gouvernance a été prise.

La perturbation est également asymétrique d’une manière que le cloud et le DevOps ne l’étaient pas. Ces transitions ont créé de nouvelles catégories de risque, mais ont largement préservé l’hypothèse qu’un humain était responsable du code expédié. L’IA érode cette hypothèse au point où il est le plus difficile de la détecter. C’est ce qui rend cette transition différente. L’exposition est invisible jusqu’à ce qu’elle ne le soit plus.

De nombreuses entreprises ont du mal à transformer l’adoption de logiciels open source en un modèle commercial durable. Qu’est-ce qui distingue les entreprises qui réussissent de celles qui échouent ?

Les organisations qui ont construit des entreprises durables sur les logiciels open source partagent une caractéristique : elles sont disciplinées quant au produit qu’elles vendent réellement. Elles ne vendent pas les logiciels open source, qui sont gratuits. Elles vendent l’expertise, le support opérationnel, l’infrastructure de gouvernance ou le service géré qui rend les logiciels gratuits viables à l’échelle de l’entreprise.

Inversement, les organisations qui échouent tendent à confondre l’adoption de la communauté avec la traction commerciale. Ce ne sont pas les mêmes choses. Un nombre élevé d’étoiles GitHub ou une grande communauté signale que les développeurs trouvent le projet utile. Cela ne signale pas que les acheteurs paieront pour cela, ou que la chose que les développeurs trouvent utile est la chose que les organisations ont vraiment besoin. La traduction de l’adoption des développeurs en valeur d’entreprise nécessite de construire quelque chose au-delà des logiciels open source eux-mêmes, et les organisations qui ne font pas clairement cette distinction dans leur positionnement, leur produit et leur mouvement de vente tendent à ne pas survivre à la transition à l’échelle.

Avec votre expérience dans la mise à l’échelle d’organisations axées sur les développeurs, quels sont les plus grands défis de leadership lors de la transition d’une croissance impulsée par le produit à des opérations à l’échelle de l’entreprise ?

Le plus grand défi est que les compétences et les instincts qui vous ont rendu réussi dans la croissance impulsée par le produit travaillent contre vous à l’échelle de l’entreprise. La croissance impulsée par le produit récompense la vitesse, l’itération en public, l’optimisation de l’expérience du développeur et le fait de laisser l’adoption conduire le mouvement commercial. Les ventes d’entreprise récompensent le processus délibéré, les relations exécutives, les cycles longs et la capacité de cartographier votre produit sur les résultats qui comptent pour les acheteurs qui ne sont pas des développeurs.

L’erreur de leadership que je vois le plus souvent est de supposer que la transition est principalement un problème de mouvement de vente. Ce n’est pas le cas. C’est un problème de conception organisationnelle. L’équipe qui a construit le produit, le positionnement et les premières relations avec les clients n’est souvent pas l’équipe qui peut exécuter le mouvement d’entreprise. Reconnaître cela sans perdre ce qui a rendu le produit digne d’être acheté est vraiment difficile. Les dirigeants qui le font bien sont ceux qui sont honnêtes sur lesquels les parties de l’organisation doivent évoluer et qui construisent les nouvelles capacités sans démonter la culture qui a créé le produit.

Vous avez travaillé à l’intersection de la sécurité et de la productivité des développeurs. Comment les entreprises peuvent-elles équilibrer la vitesse et l’innovation avec le besoin croissant de composants logiciels sécurisés et fiables ?

Le cadrage de la vitesse par rapport à la sécurité est un faux choix qui a persisté parce que l’outillage a renforcé cela. Lorsque la sécurité est mise en œuvre comme une passerelle de révision à la fin du processus de développement, c’est un goulet d’étranglement. Lorsqu’elle est mise en œuvre comme une source gérée de composants fiables que les développeurs tirent au début du processus, cela ne ralentit rien.

Ceux qui ont résolu cette tension l’ont fait en déplaçant l’endroit où la sécurité se produit. Non en révisant le code après qu’il a été écrit. Non en analysant les artefacts après qu’ils ont été construits. En gouvernant ce qui entre dans le catalogue que les développeurs et les outils IA tirent. Si la source est fiable, la vitesse n’est pas contrainte par la révision de sécurité, car le travail de sécurité s’est déroulé en amont. C’est une décision architecturale, et non culturelle. Cela nécessite un investissement dans l’infrastructure de gouvernance, mais cela n’exige pas de choisir entre aller vite et expédier en toute sécurité.

À mesure que les outils IA génèrent davantage de code et de dépendances, comment voyez-vous l’évolution du rôle des écosystèmes open source curatoriaux ou fiables au cours des prochaines années ?

Le rôle des sources open source curatoriales ou fiables va passer d’une bonne pratique à un besoin de base. Ce changement est impulsé par deux choses qui ne vont pas s’inverser.

La première est l’environnement réglementaire. Dans le paysage de 2026, être capable de démontrer la provenance logicielle est de plus en plus une exigence légale, et non une norme volontaire. Les conseils d’administration et les régulateurs posent des questions qui ne peuvent pas être répondues par les organisations qui tirent directement des registres publics.

La deuxième est la vitesse de développement de l’IA. À mesure que les outils IA génèrent plus de code et tirent plus de dépendances, le volume de composants non vérifiés entrant en production dépassera la capacité de toute organisation à les examiner manuellement. Les organisations qui ont établi un catalogue curatoriel et géré par les politiques comme source par défaut pour leurs développeurs et leurs outils IA pourront faire correspondre la vitesse de l’IA avec une gouvernance de sécurité appropriée. Les organisations qui s’appuient encore sur les registres publics et la révision manuelle feront face à un écart croissant entre la vitesse à laquelle le code est généré et la façon dont il est soigneusement évalué.

Les écosystèmes curatoriaux sont la réponse infrastructurelle à un problème que le développement IA a rendu inévitable.

En tant que l’une des rares femmes PDG dans l’espace open source et d’infrastructure, quels changements avez-vous vus dans la diversité des dirigeants au fil des ans, et qu’est-ce qui doit encore s’améliorer ?

Il y a eu un véritable changement. Lorsque j’ai commencé ma carrière, la représentation des femmes dans les rôles exécutifs dans les logiciels open source et l’infrastructure était si faible que les exceptions étaient notables. Cela est moins vrai maintenant. Il y a plus de femmes dans les postes techniques et exécutifs supérieurs, plus d’organisations qui sont passées au-delà de la phase de déclaration de diversité et qui font des changements structurels, et plus de modèles pour ce que le leadership dans cet espace peut ressembler.

Le cas d’affaires pour combler l’écart restant n’est pas abstrait. Les problèmes sur lesquels cette industrie travaille maintenant, les risques de chaîne d’approvisionnement logiciel, la gouvernance de l’IA, les changements organisationnels nécessaires pour rendre la sécurité une pratique de premier ordre, sont des problèmes difficiles. Les équipes diversifiées produisent de meilleurs résultats sur les problèmes difficiles. Non pas comme une question d’aspiration, mais comme une question de la façon dont les perspectives différentes mettent en évidence les hypothèses que les équipes homogènes manquent. Je l’ai vu directement. Les organisations qui ont fait des progrès réels sur l’appartenance, et non seulement sur la représentation, sont celles où cet avantage opérationnel se manifeste dans le travail.

L’appartenance est encore inégale dans l’industrie. Être dans la salle n’est pas la même chose que d’avoir sa perspective réellement prise en compte. C’est là que la prochaine phase de progrès doit se produire.

Je vous remercie pour cette grande interview, les lecteurs qui souhaitent en savoir plus peuvent visiter ActiveState.