Saulius Lazaravičius, VP of Product chez Hostinger – Série d’interviews

Saulius Lazaravičius, VP of Product chez Hostinger, est un leader expérimenté en technologie et produit dont la carrière s’étend sur plus de deux décennies dans le génie logiciel, l’entrepreneuriat, le commerce électronique et le développement de produits. Il a commencé comme ingénieur logiciel avant de co‑fonder une société SaaS B2B, où il a contribué à créer une plateforme de gestion du transport à partir de zéro. Il a ensuite formé et dirigé l’équipe de développement logiciel derrière BARBORA, l’une des plus grandes plateformes d’e‑commerce d’épicerie des pays baltes, avant de rejoindre NFQ, où il a géré des équipes technologiques transversales et le développement de produits pour les clients. Lazaravičius a intégré Hostinger en tant que Head of Product en 2022 et a été promu VP of Product en 2024, élargissant ses responsabilités du web‑hosting et du WordPress géré à un portefeuille complet incluant l’infrastructure de base, les VPS, les domaines, les e‑mails professionnels, la conception produit, la croissance produit et les produits d’IA émergents. Son travail récent comprend le lancement et le développement de l’offre d’email marketing de Hostinger ainsi que l’introduction de solutions gérées pour les agents IA open‑source.

Hostinger est une société technologique fondée en Lituanie qui est passée d’un fournisseur traditionnel d’hébergement web à une plateforme plus large, pilotée par l’IA, pour créer, lancer et développer des entreprises en ligne. Fondée en 2004, l’entreprise sert aujourd’hui plus de 5 millions d’utilisateurs dans plus de 150 pays et emploie environ 900 personnes. Son portefeuille de produits couvre l’hébergement web et cloud, le WordPress géré, les serveurs privés virtuels (VPS), les domaines, les e‑mails professionnels, le commerce électronique et les outils de création alimentés par l’IA. Hostinger place de plus en plus l’IA au cœur de sa stratégie, notamment avec Hostinger Horizons, qui permet aux utilisateurs de créer et publier des sites web et des applications web via une IA conversationnelle, ainsi que des capacités IA intégrées pour le commerce électronique, le support client et les agents IA gérés.

Vous avez commencé votre carrière comme ingénieur logiciel, puis vous avez construit et dirigé des équipes de développement, et aujourd’hui vous supervisez un large portefeuille de produits Hostinger couvrant l’infrastructure de base, les VPS, les domaines, la croissance produit et les solutions gérées pour les agents IA open‑source. Comment cette évolution a‑t‑elle influencé votre vision de ce dont les développeurs ont réellement besoin de l’IA au‑delà de la simple génération de code ?

Pour moi, la partie la plus intéressante du développement logiciel n’a jamais été l’écriture du code en soi. C’est de trouver la bonne solution à un problème technique ou utilisateur, de formuler une hypothèse, de construire quelque chose autour, puis de voir comment les gens l’utilisent réellement et en tirent profit.

Par le passé, une grande partie du temps du développeur était consacrée aux tâches répétitives liées à ce processus : recherche de bibliothèques et d’extraits de code, assemblage de différents éléments, débogage, tests et correction de petits problèmes avant même de pouvoir évaluer correctement la pertinence de la solution.

L’IA modifie cet équilibre. Une grande partie de ce travail répétitif peut désormais être gérée avec quelques invites, laissant aux développeurs davantage de temps pour la partie créative : comprendre le problème, explorer différentes approches, prendre des décisions produit et apprendre du comportement réel des utilisateurs.

C’est là que je vois la plus grande valeur de l’IA pour les développeurs. Il ne s’agit pas seulement de générer du code plus rapidement. Il s’agit d’éliminer davantage de tâches obligatoires mais peu intéressantes afin que les développeurs puissent consacrer plus de temps à résoudre les problèmes qui comptent réellement.

Les outils de codage IA ont considérablement réduit le temps nécessaire pour passer d’une idée à du code fonctionnel. Pensez‑vous que le déploiement et la gestion de l’infrastructure deviennent désormais les principaux goulets d’étranglement du développement logiciel assisté par l’IA ?

Oui, je pense qu’ils deviennent la prochaine source majeure de friction.

L’IA a compressé le délai entre une idée et du code exploitable de façon spectaculaire. Mais une fois le code existant, il faut encore le placer quelque part, le configurer correctement, connecter les services, gérer les domaines et la sécurité, et maintenir l’application en fonctionnement. Si ces étapes nécessitent encore de passer d’un tableau de bord à un autre, de consulter des pages de documentation, d’ouvrir des terminaux et d’utiliser différents outils, le flux de travail ralentit à nouveau.

Nous constatons que les développeurs souhaitent la même rapidité du code à la production qu’ils obtiennent désormais de l’idée au code. Plus de 19 000 clients ont déjà testé Hostinger Connector, environ 1 500 l’utilisent quotidiennement, et ils réalisent approximativement entre 30 000 et 40 000 actions par jour. C’est un signal fort que le déploiement et les opérations s’intègrent directement dans le flux de travail du développement assisté par l’IA.

Hostinger indique que son Connector traite déjà 30 000 à 40 000 actions par jour sur les sites web et les services. Que demandent réellement les développeurs aux agents IA en production, et certains de ces usages vous ont‑ils surpris ?

Les développeurs utilisent Connector directement depuis les outils dans lesquels ils travaillent déjà, comme VS Code, Antigravity et Cursor. Ce changement est important car il introduit les actions d’infrastructure dans le flux de développement au lieu d’obliger les développeurs à basculer entre différents tableaux de bord.

L’un des cas d’usage les plus clairs que nous observons est le déploiement. Plus de 14 600 sites uniques ont déjà été déployés via MCP, et les déploiements hebdomadaires ont augmenté de près de 300 % au cours du mois dernier.

Au‑delà du déploiement, les agents utilisent Connector pour gérer les domaines et le DNS, les fichiers du site, les ressources serveur, les règles de pare‑feu, les clés SSH, les tâches e‑commerce, les campagnes d’e‑mail et d’autres services Hostinger. En pratique, cela signifie qu’un agent peut passer de l’aide à la construction d’un projet à la mise en ligne et à la gestion des services qui l’entourent.

Il existe une différence importante entre laisser un agent IA écrire du code et lui permettre de modifier des enregistrements DNS, des règles de pare‑feu, des clés SSH ou des configurations serveur. Quels nouveaux garde‑fous deviennent nécessaires lorsqu’on confie à ces agents ce niveau de contrôle opérationnel ?

La différence clé est que l’agent ne se contente plus de suggérer quoi faire. Il effectue de véritables changements sur un système en production, ce qui rend la sécurité et le contrôle beaucoup plus cruciaux.

Cela implique que les agents doivent disposer de limites d’autorisation claires, d’un accès sécurisé et d’une visibilité sur les actions qu’ils exécutent. Mais idéalement, les développeurs ne devraient pas avoir à gérer toute cette complexité eux‑mêmes.

C’est l’approche que nous adoptons avec Hostinger Connector et notre plateforme d’agents. La plateforme prend en charge l’infrastructure, l’accès et les couches de sécurité autour de l’agent, afin que les développeurs puissent se concentrer sur ce qu’ils souhaitent que leurs agents fassent, plutôt que sur la configuration et la maintenance de tout ce qui se trouve en dessous.

« Vibe coding » a rendu le développement logiciel accessible à des personnes qui peuvent avoir des connaissances limitées en infrastructure ou en DevOps. Que se passe‑t‑il lorsque ces utilisateurs commencent à déployer des applications via des agents sans comprendre pleinement les systèmes sous‑jacents ?

Je pense que cela place davantage de responsabilités sur la plateforme, pas sur l’utilisateur. Si l’IA rend possible pour plus de personnes de créer des logiciels, nous ne pouvons pas attendre d’elles qu’elles deviennent également expertes en infrastructure.

La plateforme doit prendre en charge une plus grande partie de la complexité sous‑jacente, de la sécurité et des sauvegardes à la surveillance, aux limites de ressources et aux valeurs par défaut sensées. Les utilisateurs doivent comprendre ce qui se passe à un niveau élevé, mais ils ne devraient pas avoir besoin de connaissances approfondies en DevOps simplement pour mettre une application en ligne en toute sécurité.

Nous avons déjà observé un schéma similaire avec les agents IA. Avec des produits tels que Managed OpenClaw, le défi pour de nombreux utilisateurs n’était pas ce que l’agent pouvait faire, mais tout ce qui était nécessaire pour le faire fonctionner de façon fiable : hébergement, configuration, clés API, sécurité et maintenance. Supprimer ce fardeau de configuration a rendu la technologie beaucoup plus accessible.

Je pense que l’infrastructure évoluera de la même manière. Les utilisateurs devraient pouvoir se concentrer sur ce qu’ils souhaitent construire, tandis que la plateforme gère en arrière‑plan la complexité opérationnelle de façon sécurisée.

Pour qu’un agent IA exploite l’infrastructure de façon fiable, combien de contexte a‑t‑il besoin sur l’environnement environnant, comme les dépendances, les ressources serveur, les politiques de sécurité, les identifiants et les changements de configuration précédents ?

Un agent a besoin de suffisamment de contexte pour comprendre non seulement la tâche, mais aussi l’environnement qui l’entoure.

Une action simple comme modifier un enregistrement DNS, redémarrer un serveur ou déployer une nouvelle version peut impacter d’autres parties du système. Ainsi, l’agent doit avoir accès à des informations structurées sur les ressources qu’il manipule : ce qui est déployé, ce qui en dépend, quelles ressources sont disponibles, quelles permissions il possède et ce qui s’est passé auparavant.

En même temps, plus de contexte ne doit pas signifier un accès illimité. L’agent ne doit recevoir que les informations et les autorisations réellement nécessaires pour accomplir la tâche en toute sécurité. Accorder à un agent un accès excessif simplement parce qu’un contexte plus large pourrait le rendre plus « intelligent » serait le mauvais compromis.

Où l’approbation humaine doit‑elle rester obligatoire ? Existe‑t‑il des catégories d’actions d’infrastructure que vous estimez que les agents IA devraient pouvoir exécuter de façon autonome et d’autres qui devraient toujours nécessiter une autorisation humaine explicite ?

Je crois que les agents IA peuvent fonctionner largement de façon autonome, à condition que le système soit correctement configuré dès le départ.

Plutôt que de confier toutes les tâches à un seul agent, différents agents peuvent avoir des responsabilités distinctes. L’un peut gérer le codage et le déploiement, un autre tester le résultat, un troisième surveiller le système et déclencher des alertes, et un autre encore escalader les problèmes lorsqu’ils surviennent.

Dans cette configuration, l’humain n’a pas besoin d’approuver chaque action individuelle. Son rôle consiste à superviser l’ensemble du système d’agents : définir les règles, attribuer les bonnes permissions, surveiller la façon dont les agents collaborent et améliorer le paramétrage au fil du temps.

Ainsi, pour moi, la question clé ne porte pas tant sur quelles actions individuelles requièrent toujours une approbation humaine, mais plutôt sur le fait que le système global ait été conçu avec les bons contrôles, responsabilités et voies d’escalade.

À mesure que les environnements de développement deviennent des interfaces pour déployer des applications, gérer des domaines, configurer des serveurs et contrôler des services externes, pensez‑vous que les frontières traditionnelles entre l’IDE, les plateformes DevOps et les consoles de gestion cloud vont disparaître ?

Je m’attends à ce que ces frontières s’estompent considérablement, même si je ne pense pas que chaque interface spécialisée disparaisse.

Aujourd’hui, les développeurs passent souvent d’un IDE à un tableau de bord d’hébergement, à un panneau de gestion de domaine, à un terminal et à plusieurs services externes simplement pour mettre une application en production. Les agents IA peuvent relier nombre de ces étapes et les intégrer dans l’environnement où le développeur travaille déjà.

Cela ne signifie pas que les tableaux de bord ou les outils de gestion cloud disparaîtront. Ils resteront utiles pour des configurations plus approfondies et pour la supervision. Mais pour de nombreuses tâches quotidiennes, les développeurs n’auront plus besoin de réfléchir à quelle interface ouvrir ensuite.

L’expérience devient davantage centrée sur la tâche que l’on veut accomplir et moins sur l’outil qui, traditionnellement, la possédait.

Les agents IA peuvent potentiellement effectuer des changements d’infrastructure bien plus rapidement que les humains, mais ils peuvent aussi commettre des erreurs à la vitesse d’une machine. Dans quelle mesure des fonctionnalités telles que les journaux d’audit, les mécanismes de retour en arrière, les limites d’autorisation et la surveillance continue deviendront‑elles essentielles à mesure que le développement agentique mûrit ?

Ces fonctionnalités deviendront indispensables à mesure que les agents assument davantage de travaux opérationnels.

L’IA peut modifier l’infrastructure beaucoup plus rapidement qu’une personne, ce qui est utile lorsque tout se passe bien. Mais la même rapidité peut également propager une erreur très rapidement. C’est pourquoi les utilisateurs doivent savoir ce qui a changé, quelles autorisations l’agent possédait et comment récupérer en cas de problème.

Les journaux d’audit, les limites d’autorisation, la surveillance et les mécanismes de rollback sont ce qui rend ce type d’automatisation fiable.

À mesure que les agents gagnent en capacités, je pense que la qualité de ces garde‑fous sera aussi importante que l’intelligence de l’agent lui‑même.

À l’avenir, pensez‑vous que les plateformes de développement IA qui l’emporteront seront celles disposant des meilleurs modèles de codage, ou bien l’avantage concurrentiel résidera‑t‑il de plus en plus dans la capacité à offrir aux agents un accès sécurisé à l’infrastructure, aux outils, au contexte organisationnel et aux systèmes de production ?

La qualité du modèle de codage restera importante, mais je ne pense pas que cela suffise à lui seul.

Une fois que les modèles sont capables de générer du code, la question majeure devient ce qui se passe ensuite. L’agent peut‑il déployer l’application ? Peut‑il connecter les bons services, comprendre l’environnement, effectuer des changements en toute sécurité et vérifier que tout fonctionne ?

C’est là que l’accès à l’infrastructure, aux outils, aux permissions et au contexte devient beaucoup plus crucial.

Je pense que les plateformes de développement IA les plus performantes combineront de bons modèles avec un accès sécurisé aux systèmes entourant le code. La vraie valeur ne réside pas seulement dans le fait d’aider quelqu’un à écrire du logiciel plus rapidement, mais dans le fait de l’aider à passer d’une idée à un produit fonctionnel avec moins d’étapes intermédiaires.

Merci pour cet excellent entretien, les lecteurs qui souhaitent en savoir plus sur les différentes solutions d’hébergement proposées devraient visiter Hostinger.