Pour la plupart des startups d’IA, l’infrastructure n’est pas le premier problème à résoudre ; la vitesse est.
Dès les premiers stades, le succès est défini par la rapidité avec laquelle une équipe peut passer de l’idée au produit, du prototype à la traction. Les contraintes sont immédiates et impitoyables : une piste limitée, des équipes réduites et la pression constante de prouver sa valeur avant la prochaine étape de financement.
Les startups ne gagnent pas dès le début en minimisant le coût par jeton ou en optimisant les performances du silicium. Ils gagnent en comprimant le cycle allant de l'idée au produit expédié jusqu'à l'apprentissage du client – souvent en jours ou en semaines, et non en trimestres – et en répétant ce cycle plus rapidement que leurs concurrents.
Alors, ils font ce qui a du sens : ils s’appuient sur les meilleurs outils disponibles. Ils utilisent des API matures, s'appuient sur des plates-formes cloud hyperscale et donnent la priorité à la vitesse des développeurs plutôt qu'à l'optimisation au niveau du système.
Et pendant un certain temps, c'est exactement la bonne approche. Mais cela soulève une question importante : quelles décisions prises aujourd’hui en faveur de la vitesse limiteront les options demain ?
Les décisions cachées en matière d’infrastructure que les startups prennent déjà
Il y a une dynamique subtile en jeu. Même lorsque les startups ne pensent pas explicitement à l'infrastructure, les choix quotidiens qu'elles font sont la création – frameworks, plates-formes cloud, hypothèses de déploiement – façonne tranquillement ce qui sera possible plus tard.
La décision de s'appuyer fortement sur les services propriétaires d'un seul fournisseur de cloud peut accélérer le développement initial. Mais cela peut également rendre plus difficile le déplacement des charges de travail, le contrôle des coûts ou l’adaptation des architectures à long terme.
Une stratégie de modèle optimisée aujourd’hui uniquement pour faciliter l’intégration peut limiter la flexibilité demain.
Même une hypothèse aussi simple que « cela fonctionnera toujours dans le cloud » peut devenir une contrainte lorsque les clients exigent une latence plus faible, des garanties de confidentialité plus strictes ou une intelligence sur l'appareil.
La plupart des startups ne choisissent pas directement l'infrastructure. Mais ils prennent des décisions architecturales qui définissent leurs futurs degrés de liberté.
Quand l’infrastructure devient soudainement importante
À un moment donné, l’équation change. Cela ne se produit pas au stade de l'amorçage et souvent, cela ne se produit même pas lors de la série A. Mais à mesure que les startups d'IA se développent, trois pressions ont tendance à émerger :
- Les coûts commencent à compter : Ce qui était autrefois une facture cloud acceptable devient un moteur essentiel de l'économie de l'unité, en particulier pour les applications gourmandes en inférence.
- La latence devient critique pour le produit : L'expérience utilisateur – et dans certains cas, la sécurité – dépend de la réactivité en temps réel
- L’IA va au-delà du cloud : Les clients s'attendent de plus en plus à ce que l'intelligence s'exécute sur les appareils, en périphérie ou dans des environnements contrôlés.
C’est le moment où l’infrastructure passe du statut de détail de fond à celui de préoccupation stratégique. Et c'est aussi le moment où les choix antérieurs commencent à montrer leurs conséquences.
Certaines équipes découvrent qu’elles peuvent s’adapter rapidement. D'autres découvrent qu'ils se sont effectivement enfermés – confrontés à des réécritures coûteuses, à des goulots d'étranglement en termes de performances ou à des options de déploiement limitées.
Le véritable avantage : l’optionnalité architecturale
Les startups qui traversent le mieux cette transition ne sont pas celles qui ont optimisé leur infrastructure dès le premier jour. Ce sont eux qui n’ont pas sur-optimisé trop tôt, mais qui ne se sont pas non plus enfermés dans des sentiers étroits. En d’autres termes, ils ont préservé le caractère facultatif.
En pratique, cela signifie :
- Éviter une dépendance profonde à l'égard de la pile propriétaire d'un seul fournisseur
- Choisir des outils et des frameworks bénéficiant d’un large support écosystémique
- Construire en pensant que les charges de travail devront peut-être se déplacer entre les cloud, entre les environnements ou plus près de l'utilisateur
Cela ne les ralentit pas tôt. En fait, c’est souvent le contraire. Cela permet aux équipes d’avancer rapidement sans accumuler de contraintes cachées qui refont surface plus tard.
Et lorsque vient le temps d'optimiser – que ce soit en termes de coûts, de performances ou de flexibilité de déploiement – ils sont capables de le faire sans recommencer.
Le rôle de l'architecture, que vous la voyiez ou non
C’est souvent là que les plateformes de calcul sous-jacentes sur lesquelles les startups s’appuient commencent à avoir de l’importance. Aujourd’hui, l’informatique moderne s’étend aux instances cloud hyperscale, aux smartphones, aux systèmes embarqués et aux appareils de périphérie. Lorsque ces environnements partagent des fondations architecturales communes, ils peuvent créer un niveau de continuité entre les plates-formes cloud, les services d’IA et les appareils sur lesquels les startups s’appuient quotidiennement.
Une équipe peut commencer par créer et évoluer dans le cloud, à l'aide d'outils et de services standards. Mais à mesure que leurs besoins évoluent – qu’il s’agisse d’optimiser les coûts, d’améliorer l’efficacité ou de déployer des capacités d’IA en périphérie – ils peuvent le faire au sein d’une architecture qui couvre déjà ces domaines.
Au lieu de réécrire les applications ou de repenser les hypothèses fondamentales, ils peuvent s’adapter.
C’est la différence entre une architecture qui contraint les décisions et une architecture qui les maintient ouvertes.
Au-delà des GPU : un avenir plus flexible
Le débat autour de l’infrastructure de l’IA est souvent dominé par les GPU, et pour cause. Ils ont joué un rôle central dans les progrès rapides de l’IA moderne.
Mais la trajectoire à long terme est plus hétérogène.
Les systèmes d’IA sont de plus en plus construits à partir d’un mélange d’éléments de calcul – CPU, GPU, NPU et accélérateurs spécialisés – travaillant ensemble pour gérer différentes parties de la charge de travail. Ce changement permet une optimisation plus précise, une meilleure utilisation des ressources et des performances améliorées dans un plus large éventail de cas d’utilisation.
Pour les startups, cela ne signifie pas gérer cette complexité directement dès le premier jour. Dans la plupart des cas, ces informations restent abstraites par les fournisseurs et les plateformes cloud.
Mais cela renforce l’importance de bâtir sur des fondations capables de soutenir cette diversité au fil du temps, sans nécessiter une refonte fondamentale.
Choisir ce qu’il ne faut pas décider – pour l’instant
La plus grande erreur que les startups d’IA puissent commettre est de ne pas ignorer l’infrastructure dès le début. Il s'y enferme trop tôt.
Les équipes les plus efficaces se concentrent d’abord sur la rapidité et l’adéquation produit-marché. Mais ils le font d’une manière qui évite les contraintes inutiles, gardant leurs options ouvertes au fur et à mesure de leur croissance.
Car si les infrastructures ne sont pas le premier problème à résoudre, elles deviennent inévitablement l’un des plus importants. Et lorsque cela se produira, les startups qui gagneront ne seront pas celles qui auront optimisé le plus tôt.
Ce seront eux qui choisiront des architectures qui leur permettront d'évoluer – sans recommencer.
Paul Williamson est vice-président senior des projets stratégiques chez Arm Holdings Ltd., où il dirige les investissements stratégiques et les initiatives de fusions et d'acquisitions. Il a écrit cet article pour SiliconANGLE.
