Kris Beevers, PDG et co-fondateur, Netbox Labs – Série d’interviews

Kris Beevers, PDG et co-fondateur de NetBox Labs est un entrepreneur technologique et vétéran des logiciels d’infrastructure avec plus de deux décennies d’expérience dans la création d’entreprises et de plateformes axées sur le réseau, l’infrastructure cloud et l’automatisation. Avant de diriger NetBox Labs, Beevers a cofondé NS1 en 2013 et en a été le PDG pendant près d’une décennie, faisant de l’entreprise un fournisseur de premier plan de technologies d’automatisation réseau et de gestion du trafic applicatif avant son acquisition par IBM en 2023. Dans le cadre de cette transaction, NetBox Labs s’est scindé de NS1 en tant qu’entreprise indépendante avec IBM comme investisseur. Au début de sa carrière, Beevers a occupé des postes d’ingénierie senior et d’architecture chez Internap Network Services et Voxel, et il a également cofondé SolidJoint Research.

NetBox Labs développe une plateforme d’intelligence d’infrastructure conçue pour aider les organisations à modéliser, exploiter, automatiser et gouverner des réseaux et une infrastructure informatique de plus en plus complexes. L’entreprise est le gestionnaire commercial de NetBox, le système d’enregistrement de réseau et d’infrastructure open source largement adopté, utilisé par plus de 10 000 organisations. Sa plateforme combine un graphe d’infrastructure et une source de vérité avec une intelligence opérationnelle, de l’automatisation, de l’orchestration assistée par IA et des capacités de gouvernance qui permettent aux ingénieurs comme aux agents IA d’interagir en toute sécurité avec l’infrastructure. NetBox Labs prend en charge les déploiements cloud, en entreprise auto‑gérée, hybrides et isolés, tout en s’intégrant à des outils tels qu’Ansible, Terraform, Nornir et aux pipelines d’intégration et de déploiement continus.

Vous avez cofondé NS1 en 2013 et avez passé près d’une décennie à développer l’entreprise avant son acquisition par IBM, après quoi NetBox Labs est devenue une société indépendante. Quelles leçons tirées de la construction de NS1 ont influencé votre décision de fonder NetBox Labs, et comment le problème d’infrastructure que vous cherchez à résoudre a-t-il changé à l’ère de l’IA ?

Une chose que j’ai apprise en construisant NS1 est que les problèmes d’infrastructure restent rarement bien confinés. Le DNS était notre partie de la pile, mais nos clients exploitaient ces environnements incroyablement complexes où les réseaux, les centres de données, les applications et l’automatisation dépendaient les uns des autres. Plus je passais de temps avec ces équipes, plus il devenait clair que comprendre l’infrastructure elle‑même était un problème bien plus vaste.

Cela a été une grande partie de ce qui m’a attiré vers NetBox. Il existait déjà ce projet open source largement adopté et une communauté d’ingénieurs l’utilisant pour modéliser ce qu’ils possédaient, comment c’était connecté et à quoi cela devait ressembler. Nous avons vu une opportunité de construire sur cette base.

Ce qui a changé avec l’IA, c’est surtout le rythme et l’échelle. Les équipes d’infrastructure se voient demander de construire des environnements énormes à une vitesse incroyable, tandis que la technologie sous‑jacente évolue tout aussi rapidement. En même temps, nous commençons à automatiser davantage le fonctionnement de cette infrastructure, ce qui représente un avenir prometteur. À mesure que l’IA est appliquée à l’infrastructure, les équipes informatiques réalisent qu’elles doivent disposer de données fiables et en temps réel sur leur infrastructure pour pouvoir automatiser, et elles doivent connaître l’état souhaité afin que l’IA puisse les aider à identifier quand l’infrastructure opérationnelle s’écarte du plan.

La leçon tirée de NS1 reste valable. Avant de pouvoir automatiser correctement l’infrastructure, il faut la comprendre. L’IA ne fait que rendre cette exigence encore plus urgente.

Pendant la majeure partie de la dernière décennie, le cloud computing a permis aux développeurs et aux équipes d’infrastructure d’abstraire le matériel physique sous leurs applications. Pourquoi l’IA renverse‑t‑elle cette tendance et oblige‑t‑elle les équipes DevOps, Site Reliability Engineering (SRE) et les ingénieurs réseau à repenser à nouveau l’alimentation, le refroidissement, les racks, le câblage et le réseau physique ?

Le cloud nous a appris à considérer l’infrastructure comme pratiquement infinie. Vous demandiez de la puissance de calcul et elle apparaissait. Vous n’aviez pas nécessairement à vous soucier de l’endroit où se trouvait le serveur, de la façon dont il était alimenté, refroidi ou de la manière dont toutes les pièces physiques sous‑jacent s’assemblaient.

L’infrastructure IA ne vous permet pas vraiment de faire cela.

Lorsque vous construisez ces environnements, vous commencez par des questions très concrètes. Quelle superficie de terrain ai‑je ? Quelle puissance puis‑je obtenir ? Quel type de refroidissement puis‑je supporter ? À partir de là, vous passez aux racks, aux serveurs GPU, aux commutateurs, au câblage à fibre optique et finalement à la couche logique, aux adresses IP, aux configurations et aux logiciels.

Ces éléments dépendent tous les uns des autres. Vous ne pouvez pas décider du nombre de racks à déployer sans comprendre la densité d’alimentation et de refroidissement. Vous ne pouvez pas envisager les GPU indépendamment du réseau qui les relie.

Cela oblige des disciplines qui ont passé des années à s’éloigner de la couche physique à s’y réengager. L’abstraction n’a pas disparu, mais les contraintes physiques sous‑jacentes prennent soudainement beaucoup plus d’importance.

Les centres de données IA sont de plus en plus évoqués à l’échelle du gigawatt. Qu’est‑ce qui change fondamentalement sur le plan opérationnel lorsque l’infrastructure passe d’environnements d’entreprise ou de cloud conventionnels à des installations conçues autour d’énormes grappes de GPU ?

L’échelle du gigawatt est absolument astronomique. Mais bien que l’échelle soit évidemment différente, je pense que la différence la plus intéressante réside dans le niveau de coordination requis.

Imaginez ce qu’il faut faire pour mettre en service un centre de données de 300 MW. Il faut du terrain et de l’électricité. Ensuite, il faut concevoir l’installation et se procurer des racks, des serveurs GPU, des commutateurs, de la fibre, des infrastructures d’alimentation et de refroidissement, souvent auprès de fournisseurs complètement différents avec des modes de représentation de leurs produits totalement distincts. Tout cet équipement doit arriver, être réceptionné, installé en rack, câblé, configuré, testé et finalement remis pour la formation ou l’inférence.

Et le sol bouge sous vos pieds pendant que vous le faites. Les architectures GPU évoluent. Le réseau change. Les exigences de refroidissement se transforment. Les composants disponibles dans six mois ne seront peut‑être pas les mêmes que ceux autour desquels vous avez conçu aujourd’hui.

Ainsi, de petites inefficacités s’accumulent très rapidement. J’ai récemment passé du temps avec l’un des plus grands fabricants de câbles à fibre optique au monde, et ils m’ont confié que l’un de leurs plus gros problèmes commerciaux était les retours, car les clients commandent des longueurs de câble inadaptées. Cela semble presque anodin jusqu’à ce que l’on commande des centaines de milliers de câbles.

À cette échelle, les opérations d’infrastructure deviennent un gigantesque problème logistique et de satisfaction de contraintes. Les entreprises qui réussissent le mieux sont celles qui maîtrisent parfaitement la transmission des données de conception précises tout au long du processus d’approvisionnement, de déploiement et d’exploitation.

Vous avez déclaré qu’il n’existe pratiquement aucun manuel établi ni aucun vivier de talents pour exploiter l’infrastructure à cette échelle. Quelles compétences sont actuellement les plus difficiles à trouver, et où prévoyez‑vous les plus grandes pénuries de talents à mesure que l’infrastructure IA se développe ?

Il n’y a probablement que quelques centaines de personnes dans le monde aujourd’hui qui savent réellement comment construire ce type d’infrastructure à cette vitesse et à cette échelle. Et la plupart d’entre elles sont déjà très occupées à le faire.

C’est en partie ce qui rend ce moment inhabituel. Il n’existe pas un corpus de connaissances mature que l’on puisse simplement étudier. Les personnes qui le font apprennent les unes des autres et résolvent les problèmes en temps réel. Et comme la technologie évolue si rapidement, certaines de ces leçons deviennent rapidement obsolètes.

Je pense donc que la pénurie dépasse tout titre de poste. Nous avons besoin de personnes qui comprennent le réseau, le calcul et l’automatisation, mais qui comprennent de plus en plus l’environnement physique dans lequel ces systèmes évoluent. L’alimentation, le refroidissement, la conception des installations, la chaîne d’approvisionnement et les opérations sur le terrain font désormais partie de la même conversation.

Les personnes capables de franchir certaines de ces frontières seront incroyablement précieuses. Mais je ne pense pas que nous ayons encore défini à quoi ressembleront tous ces rôles. Le modèle de talents se construit en même temps que l’infrastructure.

À mesure que les frontières entre logiciels, réseaux, installations, énergie et ingénierie des centres de données commencent à s’estomper, quels nouveaux rôles techniques ou ensembles de compétences hybrides prévoyez‑vous voir émerger ?

Je ne pense pas que nous sachions encore à quoi ressembleront tous ces rôles. Ce que nous savons, c’est que les personnes qui construisent cette infrastructure doivent réfléchir à un ensemble de problèmes bien plus large qu’auparavant.

Vous ne pensez plus uniquement au calcul ou au réseau isolément. L’alimentation, le refroidissement, la conception physique, la chaîne d’approvisionnement, le réseau et l’automatisation doivent tous converger pour mettre ces environnements en ligne et les maintenir en fonctionnement.

Je continue de penser que nous aurons besoin de personnes possédant une expertise approfondie dans chacun de ces domaines. Mais, de plus en plus, elles devront également comprendre comment les décisions dans leur domaine affectent le reste de l’infrastructure. Et comme tant de ces travaux doivent être réalisés plus rapidement, la capacité à automatiser deviendra cruciale dans davantage de disciplines.

Les agents IA commencent à diagnostiquer les problèmes, à générer des configurations et à automatiser certaines parties des opérations d’infrastructure. Quelles responsabilités pensez‑vous que l’IA prendra réellement en charge auprès des ingénieurs d’infrastructure, et lesquelles deviendront encore plus dépendantes d’une expertise humaine profonde ?

Je pense qu’une grande partie du travail où les entrées, le résultat souhaité et les limites sont clairement définis sera de plus en plus prise en charge par l’IA. La génération de configurations en est un exemple évident. Il en va de même pour le diagnostic de problèmes courants, la vérification de la conformité de l’infrastructure au design prévu, ou éventuellement la résolution de certains problèmes lorsqu’on dispose d’une confiance suffisante quant à la cause du dysfonctionnement et à la réponse sécuritaire à adopter.

Là où les humains deviennent plus importants, c’est lorsque la réponse n’est pas évidente.

L’infrastructure échoue de façon étrange. Une fibre est coupée. Un dispositif commence à se comporter différemment de ce que le design indique. Un changement a un effet inattendu ailleurs dans l’environnement. L’IA peut aider un ingénieur à comprendre ces situations beaucoup plus rapidement, mais il faut toujours des personnes qui comprennent le système en profondeur pour décider de la suite à donner.

Je pense que c’est le changement intéressant. Les ingénieurs passeront probablement moins de temps à effectuer des configurations et des dépannages répétitifs et davantage à définir l’intention, concevoir les systèmes, fixer les limites de l’automatisation et gérer les problèmes réellement nouveaux. Tout ce travail sera complété par l’IA, mais guidé par les humains.

Cela rend l’expertise plus précieuse, pas moins. L’ingénieur qui comprend réellement pourquoi l’infrastructure fonctionne comme elle le fait sera d’une importance capitale lorsque l’automatisation n’aura pas de réponse évidente.

NetBox Labs soutient que les systèmes d’IA qui gèrent l’infrastructure ont besoin d’un modèle autoritaire des appareils, des connexions, des dépendances et d’autres relations physiques et logiques. Pourquoi ce type de contexte d’infrastructure est-il si important lorsqu’on passe d’assistants IA qui font des recommandations à des agents capables d’agir réellement ?

La grande différence, c’est que lorsqu’un agent peut agir, se tromper entraîne de réelles conséquences.

Un agent d’infrastructure a besoin de plus qu’une simple capture instantanée de ce que fait un appareil à l’instant T. Il doit comprendre l’environnement qui l’entoure : ce qui existe, comment les éléments sont connectés, ce qui a changé récemment et, surtout, à quoi l’infrastructure est censée ressembler.

Prenons par exemple le dépannage d’un problème de connectivité. Il ne suffit pas de savoir qu’un appareil est injoignable. Vous voulez que l’agent puisse tracer le chemin du câble, comprendre les dépendances autour de cet appareil, examiner les changements récents et déterminer ce qui pourrait être affecté avant de proposer la prochaine action.

C’est vraiment le socle sur lequel nous avons passé des années à travailler chez NetBox Labs, en offrant aux équipes un modèle précis de l’infrastructure physique et logique, ainsi que l’intention qui sous-tend son fonctionnement.

Mais les seules données ne suffisent pas. Il faut également définir ce que l’agent est autorisé à faire de façon autonome, ce qui nécessite l’approbation d’une personne, et comment chaque action est suivie et validée.

L’infrastructure n’est pas comme du code où une mauvaise modification peut toujours être annulée proprement. Une mauvaise modification peut mettre à l’arrêt une opération. Ainsi, à mesure que nous passons d’une IA qui indique à un ingénieur ce qu’elle pense à une IA capable d’exécuter le travail, le contexte et le contrôle deviennent beaucoup plus cruciaux.

Dans votre recent CIO article, « Why I, the CEO, am personally building our AI strategy », vous avez soutenu que l’IA est trop importante pour que les dirigeants d’entreprise la délèguent simplement et vous avez décrit le prototypage personnel avec des outils d’IA. Comment le fait d’être directement impliqué avec ces systèmes a-t-il modifié votre vision de ce que l’IA peut réellement automatiser dans les opérations d’infrastructure ?

Être directement impliqué vous rend beaucoup moins intéressé par les discussions théoriques.

J’ai passé beaucoup de temps à construire réellement avec ces outils, le plus souvent ces jours‑ci à prototyper ou même à créer des produits complets avec Claude Code. On apprend très vite qu’il y a une énorme différence entre voir une démonstration impressionnante et bâtir quelque chose en qui on a réellement confiance pour accomplir un travail utile.

Vous développez également une intuition sur la direction que prend la technologie, bien plus rapidement que ce que vous pouvez obtenir en lisant à son sujet. Des choses que je considérais difficiles à automatiser il y a six mois peuvent soudainement devenir assez simples. En même temps, vous voyez très clairement où le contexte, le jugement et la structure font encore défaut.

Cela a influencé ma façon de penser aux opérations d’infrastructure. Je suis très optimiste quant à la quantité de travail opérationnel que nous pouvons automatiser, mais je pense que nous sommes encore loin d’une autonomie totale comme objectif final.

La question qui m’importe est beaucoup plus fondamentale. Cela nous aide‑t‑il à exploiter l’infrastructure plus rapidement, plus fiablement ou plus efficacement ? Si oui, tant mieux. Si non, peu importe le degré de sophistication de l’IA qui se cache derrière.

À mesure que les centres de données IA deviennent de plus en plus limités par la disponibilité d’électricité et les exigences de refroidissement, l’ingénierie d’infrastructure pourrait‑elle évoluer d’une gestion principalement axée sur les ressources informatiques vers une coordination active des charges de travail avec l’énergie et la capacité physique ?

Oui, et nous commençons déjà à le voir. Nous avons une expression en interne, « turbines in the parking lot », qui vient d’une vraie conversation avec l’une des équipes qui construit l’infrastructure IA hyperscale. Ils mettaient l’infrastructure en ligne si rapidement que le réseau électrique ne pouvait pas suivre, alors ils achetaient littéralement des turbines et les installaient sur le parking pour obtenir suffisamment d’énergie rapidement.

C’est le type d’environnement dans lequel ces équipes opèrent. Lorsque l’énergie devient l’une de vos contraintes principales, vous devez devenir beaucoup plus intelligent quant à l’utilisation de ce qui est disponible. La réponse à la demande, où les opérateurs coordonnent activement les charges de travail IA en réaction aux variations du réseau électrique, se produit déjà et devient une capacité de plus en plus importante pour les équipes qui gèrent des infrastructures gourmandes en énergie.

Toutes les charges de travail n’ont pas les mêmes exigences. L’inférence sensible à la latence peut devoir rester en ligne, tandis que certaines charges d’entraînement ou de traitement par lots peuvent être déplacées ou mises en pause lorsque l’énergie est limitée. Je pense que nous verrons de plus en plus les équipes d’infrastructure gérer le calcul, l’énergie et la capacité physique comme des parties du même problème opérationnel.

En regardant vers l’avenir, pensez‑vous que le principal goulot d’étranglement à la mise à l’échelle de l’IA sera finalement les GPU et le développement de modèles, ou le défi beaucoup plus large de trouver suffisamment d’énergie, d’infrastructure physique, de capacité réseau, d’automatisation et d’ingénieurs qualifiés pour faire fonctionner tout cela ?

Je ne pense pas qu’il y aura un seul goulot d’étranglement.

Construire l’infrastructure IA à la vitesse et à l’échelle que le marché exige actuellement revient essentiellement à un problème de satisfaction de contraintes. À chaque instant, quelque chose constitue la contrainte principale.

Pendant un certain temps, tout le monde parlait des GPU. L’alimentation est évidemment un goulet d’étranglement majeur aujourd’hui. Mais cela peut aussi être le matériel réseau, le refroidissement, le terrain, la fibre, les achats, la construction, ou simplement trouver suffisamment de personnes qui savent comment assembler tout cela.

Et une fois que vous résolvez une contrainte, une autre devient plus visible. C’est ce qui se produit lorsque la demande dépasse largement l’offre.

Je ne miserais donc pas sur un goulet d’étranglement permanent. Je pense que la capacité la plus importante est de pouvoir s’adapter à mesure que la contrainte évolue.

C’est aussi la raison pour laquelle je ne pense pas que quelqu’un possède actuellement le guide définitif de l’infrastructure IA. Les personnes qui la construisent découvrent cela en même temps qu’elles augmentent leur capacité, et elles le font toutes deux à une vitesse incroyable.

Merci pour cette excellente interview, les lecteurs qui souhaitent en savoir plus devraient visiter NetBox Labs.