27 juin 2026
Ce que Google et Microsoft m'ont appris sur le déploiement à l'échelle
Leçons personnelles tirées de Google et Microsoft pour déployer des systèmes IA fiables : culture d'ingénierie, observabilité, documentation, vitesse et expérimentation.
L'échelle commence avant le trafic
Quand je repense à mes six années chez Google puis à mes deux années chez Microsoft, je ne pense pas d'abord aux datacenters ou aux systèmes distribués qui font rêver les conférences. Je pense à des revues de conception concrètes, à des postmortems sans théâtre, à des documents retrouvables trois ans plus tard, et à cette obsession presque banale : quelqu'un pourra-t-il encore comprendre, opérer et corriger ce système quand l'équipe initiale aura changé ?
Cette question est revenue dans presque tous les projets IA que j'ai livrés depuis. Beaucoup d'équipes de taille moyenne abordent les LLM comme un sujet de modèle : quel provider, quel contexte, quel prompt, quel agent. C'est normal, car c'est la partie visible. Mais dès que le système touche un workflow métier réel, l'échelle signifie plus de cas limites, de dépendances, de responsabilité, et moins de tolérance pour les réponses impossibles à expliquer.
Le premier enseignement des grandes cultures d'ingénierie est donc simple : l'échelle commence avant le trafic. Elle commence quand on décide ce qui doit être prévisible, observable, documenté et réversible. Un assistant LLM interne utilisé par cinquante personnes peut déjà être un système à l'échelle s'il influence des décisions commerciales, des réponses clients ou des opérations sensibles. À l'inverse, une démo très visible peut rester un jouet si personne ne dépend vraiment de son résultat.
Ce que l'entreprise fait vraiment bien
Google m'a appris la valeur de la fiabilité comme discipline quotidienne. Pas la fiabilité abstraite que l'on met dans une slide, mais celle qui oblige à nommer les modes de panne, à définir les invariants, à surveiller les signaux qui comptent et à accepter qu'un système sans propriétaire clair est déjà en train de dériver. Pour l'IA générative, cela veut dire que l'on ne peut pas se contenter de mesurer la beauté moyenne des réponses. Il faut savoir quand le système ne sait pas, quand il hallucine, quand la donnée source est absente, quand un outil externe échoue, et ce que l'utilisateur doit voir dans chaque cas.
Microsoft m'a davantage marqué par la maturité des environnements entreprise : sécurité, intégration, gouvernance, compatibilité avec des habitudes déjà installées. Dans une grande organisation, un bon produit n'est pas celui qui exige que tout le monde change de système demain matin. C'est celui qui respecte les identités, les permissions, les flux d'approbation, les formats de documents, les contraintes juridiques et les équipes support. Les projets LLM ratent souvent ce point. Ils répondent bien dans un bac à sable, puis échouent quand ils doivent vivre dans SharePoint, Teams, Salesforce, un intranet ancien ou un processus de validation métier.
La troisième force des grandes entreprises est la documentation. Elle crée une mémoire opérationnelle qui compte encore plus dans un projet IA, parce que les comportements ne sont pas toujours déductibles du code. Pourquoi ce prompt est-il écrit ainsi ? Quelles données ont été exclues ? Quelles erreurs ont été acceptées ? Quel seuil déclenche une revue humaine ? Si ces décisions ne sont pas écrites, l'équipe perd progressivement le contrôle du système.
Ce que cette culture fait moins bien
L'autre côté de cette rigueur, je l'ai aussi vu de près : les grandes organisations savent parfois rendre chaque changement trop cher. Une revue de plus, un comité de plus, une dépendance de plus, et l'on protège le système contre le risque au point de le protéger aussi contre l'apprentissage. C'est particulièrement dangereux avec les LLM : modèles, coûts et usages changent vite, et certaines décisions ne se prennent qu'en observant de vrais utilisateurs face à un vrai workflow.
Beaucoup d'équipes héritent donc d'un mauvais réflexe : elles veulent concevoir l'architecture parfaite avant de tester le comportement humain. Elles passent des semaines à discuter du framework agentique, du graphe d'orchestration ou de la stratégie multi-modèles, alors que le risque principal est ailleurs : confiance utilisateur, ambiguïté des données, ou gain de temps trop faible pour changer une habitude. L'ingénierie sérieuse ne remplace pas l'expérimentation. Elle doit la rendre moins dangereuse et plus lisible.
C'est là que les scale-ups ont un avantage si elles savent l'utiliser. Elles peuvent décider vite, réduire le périmètre, tester avec une équipe réelle, corriger en quelques jours, puis industrialiser ce qui mérite de l'être. Mais elles perdent cet avantage lorsqu'elles copient la lenteur des grands groupes sans en copier les mécanismes de fiabilité. Le pire des deux mondes est fréquent : beaucoup de réunions, peu de logs, une démo impressionnante, aucune évaluation reproductible, et personne capable d'expliquer pourquoi la réponse d'hier était meilleure que celle d'aujourd'hui.
Traduire ces leçons aux déploiements LLM
Quand je déploie aujourd'hui un système IA pour une entreprise de taille moyenne, j'essaie de combiner ces deux cultures. Le périmètre doit rester petit au départ, mais les fondations ne doivent pas être improvisées. Je veux un cas d'usage assez étroit pour apprendre vite, et assez réel pour révéler les contraintes de production : les permissions, les exceptions, les données sales, les conversations incomplètes, les retours utilisateurs et les cas où le système doit refuser de répondre.
Concrètement, cela commence par l'observabilité. Un système LLM en production doit laisser une trace exploitable : version du prompt, modèle utilisé, documents récupérés, appels d'outils, latence, coût, score d'évaluation, feedback utilisateur, et raison d'un éventuel fallback. Sans cela, on discute des impressions. Avec cela, on peut comparer deux versions, identifier une mauvaise source, réduire le coût sans perdre de qualité, ou décider qu'une tâche doit rester humaine.
Ensuite vient la documentation produit, pas seulement la documentation technique. Il faut écrire ce que le système est censé faire, ce qu'il ne fera pas, ce qui compte comme une bonne réponse, ce qui compte comme une erreur acceptable, et ce qui doit déclencher une escalade. Pour un agent support, ce n'est pas un détail. Pour un assistant de revue de contrats, ce n'est pas un luxe. Pour une chaîne de génération de contenu, c'est la différence entre un outil que l'équipe améliore et une boîte noire que l'équipe finit par contourner.
Le bon niveau de sérieux
Le piège, pour les dirigeants techniques, est de croire qu'il faut choisir entre la vitesse de la startup et la rigueur de l'entreprise. Mon expérience dit l'inverse. Les meilleurs déploiements IA sont rapides parce qu'ils sont rigoureux sur les bons points. Ils ne cherchent pas à tout verrouiller. Ils verrouillent les décisions irréversibles, les frontières de responsabilité, les mécanismes de mesure, et les chemins de retour en arrière. Le reste doit rester expérimental assez longtemps pour que l'équipe apprenne vraiment.
Dans la pratique, cela veut dire livrer une première version opérable : un workflow précis, quelques utilisateurs exigeants, des traces complètes, une revue hebdomadaire, une liste courte d'échecs connus, et une décision explicite sur la suite. On ne gagne pas la confiance d'un CTO en promettant que le modèle va s'améliorer. On la gagne en montrant que le système peut être observé, corrigé, limité et amélioré sans dépendre d'une seule personne héroïque.
C'est peut-être la leçon la plus durable de Google et Microsoft : la technologie change vite, mais la confiance se construit lentement. Les LLM rendent certaines capacités incroyablement accessibles. Ils ne suppriment pas la nécessité de concevoir des systèmes que l'on peut comprendre. Pour les scale-ups, l'opportunité est immense : prendre la vitesse des nouvelles briques IA, ajouter juste assez de culture d'ingénierie d'entreprise, et livrer des outils qui ne se contentent pas d'impressionner en démo, mais qui tiennent quand le travail réel commence.