Établir un pont entre les équipes d’infrastructure et de produits : les leçons tirées de la construction de plateformes GenAI

Il n’y a aucun doute : l’intelligence artificielle générative, ou GenAI, est le sujet du jour, et ce depuis déjà quelques années. Que l’objectif soit d’automatiser les processus, de générer de nouveaux designs de produits, de créer du contenu ou de nombreuses autres fonctionnalités à travers différents domaines, il est temps pour les organisations de commencer à faire le travail qui compte le plus et de mettre leurs stratégies GenAI en mouvement.

Le succès de la GenAI, allant des charges de travail de recherche à la formation et enfin à l’inférence, dépend d’une coordination étroite autour du déploiement, de l’observabilité, de la gestion des coûts, de la télémétrie et des objectifs de latence de l’infrastructure et des services sous-jacents. Ces éléments contribuent à un niveau d’efficacité réalisable pour la charge de travail de l’IA, en garantissant un équilibre efficace entre calcul et communication, en s’assurant que les GPU disposent toujours des données nécessaires.

Le défi est qu’il existe souvent un écart structurel : l’ingénierie d’infrastructure se concentre sur la pile de calcul et de déploiement, tandis que les équipes de logiciels et de produits se concentrent sur la construction d’applications orientées utilisateur qui amènent la GenAI dans le monde réel. Lorsque ces groupes ne sont pas entièrement alignés, cela entraîne souvent des retards de livraison, des problèmes de performances et des problèmes d’utilisabilité.

Alors, à quoi ressemble cet écart dans le monde réel, et quelles stratégies les organisations peuvent-elles utiliser pour aligner les équipes d’infrastructure et de produits pour le succès de la GenAI ?

Les problèmes de désalignement

Lorsque les équipes d’infrastructure et de produits sont désalignées, les symptômes sont souvent évidents, mais ne sont pas toujours traités suffisamment rapidement. Un signe caractéristique d’équipes déconnectées est les hypothèses incohérentes concernant les attentes de latence ou les capacités des modèles. Par exemple, les équipes d’ingénierie d’infrastructure peuvent planifier des fonctionnalités ou des déploiements qui supposent des niveaux de performances que la conception réelle de l’infrastructure ne correspond pas. Cela conduit à des révisions tardives, à des changements de portée et à des retards de livraison.

Le désalignement peut également entraîner de mauvaises performances en raison du déploiement sur une infrastructure non optimisée pour les rails, ce qui se manifeste par des variations de latence et des problèmes de scalabilité qui affectent les performances de la formation ou des travaux d’inférence distribués importants. Les risques de sécurité et de conformité en aval sont également des caractéristiques du désalignement des équipes, car un manque de collaboration précoce entre les deux équipes signifie que les exigences de confidentialité et de conformité des données peuvent être négligées.

Et enfin, le désalignement des équipes conduit à une mauvaise expérience utilisateur, ce qui amène les équipes d’ingénierie d’infrastructure à recourir à des solutions de contournement lorsque les contraintes ne sont pas claires, ralentissant les cycles d’itération et augmentant la dette technique. Bien sûr, le désalignement entre les équipes de produits et d’infrastructure peut être coûteux dans n’importe quel projet logiciel, mais avec la GenAI en particulier, les enjeux sont beaucoup plus élevés — inefficacités opérationnelles accrues, érosion de l’avantage concurrentiel et risques de sécurité, entre autres.

Pont vers le succès

Le succès de la GenAI dépend non seulement de l’avoir une infrastructure robuste, mais également de la création d’un cadre tactique qui relie les processus d’infrastructure et de produits. Prenons, par exemple, l’idée d’API internes d’autoservice pour la mise à disposition de GPU. Pour les équipes d’infrastructure, ces API standardisent l’accès, réduisent la charge des tickets et assurent la conformité ; pour les équipes de produits, elles offrent un accès rapide et prévisible au calcul sans avoir à attendre dans une file d’attente. Le résultat est que les deux groupes travaillent à partir du même « contrat » d’API, supprimant les goulets d’étranglement et clarifiant les attentes.

Les tableaux de bord d’utilisation en temps réel jouent un rôle similaire. Ils donnent aux ingénieurs d’infrastructure une visibilité sur la charge du système et l’efficacité, tout en montrant aux équipes de produits comment leurs charges de travail se traduisent en consommation réelle. Puisque les deux côtés voient les mêmes données, les discussions sur les performances ou les goulets d’étranglement deviennent plus collaboratives et moins conflictuelles — il y a une source unique de vérité.

L’auto-mise à l’échelle est un autre mécanisme unificateur. Elle soulage les ingénieurs d’infrastructure de la lutte constante contre les incendies, tout en s’assurant que les développeurs de produits n’atteignent pas les plafonds de performances pendant les pics de charge de travail. Ce qui pourrait autrement être un conflit entre stabilité et agilité devient une stratégie commune : la mise à l’échelle est gérée automatiquement, alignée à la fois sur la résilience opérationnelle et les objectifs de performances des produits.

Enfin, les informations sur les coûts ajoutent une dimension financière à cette vue partagée. Les équipes d’infrastructure peuvent optimiser les allocations et justifier la planification de capacité, tandis que les équipes de produits acquièrent une appréciation de la manière dont leurs choix architecturaux ou de modèles affectent les dépenses. Cette transparence favorise une responsabilité partagée, transformant l’efficacité en une responsabilité collective plutôt qu’en une préoccupation cachée.

Mais l’alignement nécessite plus que des outils partagés — il nécessite également une vision partagée. C’est là que les feuilles de route communes entrent en jeu : chaque équipe doit non seulement comprendre les objectifs globaux, mais également les étapes nécessaires pour les atteindre. Pour l’infrastructure, cela signifie regarder au-delà de ses racines techniques profondes dans le matériel et les logiciels pour s’engager dans la manière dont les développeurs et les utilisateurs finaux expérimentent réellement le système. Pour les équipes de produits, cela nécessite un respect pour les contraintes telles que la latence, le coût et l’efficacité du modèle, en appréciant les réalités opérationnelles qui rendent l’innovation durable.

Enfin, aucune partnership ne peut durer sans un engagement mutuel en faveur de la sécurité et de la conformité. Que les cadres SOC2, HIPAA, ISO ou d’autres s’appliquent, les exigences spécifiques varient en fonction de la base de clients et du secteur vertical — mais la responsabilité est partagée. Les équipes d’infrastructure et de produits doivent internaliser ces obligations, en reconnaissant que la conformité n’est pas un exercice de case à cocher, mais un fondement de confiance avec les utilisateurs.

Pris ensemble, ces pratiques et ces mentalités tissent l’infrastructure et les produits en une unité cohérente, avec un langage partagé, une visibilité partagée et une responsabilité partagée pour les progrès, la résilience et la fiabilité.

Équipes compétentes

Avoir les bonnes personnes est tout aussi important que d’avoir les bons systèmes. Idéalement, les équipes devraient inclure des membres qui connaissent déjà leur chemin dans la GenAI, ou ceux qui viennent de l’informatique à haute performance et de l’expérience des centres de données hyperscale. Ce qui compte vraiment, c’est l’expérience pratique et les leçons que l’on ne peut obtenir qu’en construisant et en soutenant des plateformes de services de GPU. Cela signifie comprendre comment les GPU communiquent entre eux, comment les formations fortement couplées se comportent, et à quel point elles sont sensibles à la latence, à la synchronisation et à la livraison de données.

Alors que les modèles continuent de grandir et que les déploiements s’étendent, les équipes doivent également reculer et réfléchir au parcours complet du client. Il commence par la recherche et l’expérimentation précoce, passe par la formation à grande échelle, puis par l’ajustement fin et enfin par l’inférence. Chacune de ces phases a un peu l’air différente, et les besoins changent au fur et à mesure. La nature itérative du développement de modèles nous enseigne constamment quel type d’infrastructure, de flux de travail et de capacités est requis pour maintenir un centre de données GenAI adapté à son objectif.

Trop souvent, les équipes d’infrastructure et de produits opèrent dans leurs propres bulles. Pour toute entreprise sérieuse à propos de la mise à l’échelle de la GenAI en production, cela doit changer. Le succès dépend de la suppression de ces silos et de la création d’une propriété partagée de la plateforme. Avec les bonnes personnes, une vision claire et un cadre pratique, les deux côtés peuvent s’aligner sur le même livre de jeu — celui qui les aide à aller plus vite, à rester responsables et à livrer finalement des déploiements de GenAI réussis.