Plaidoyer pour le petit studio d'IA
Pourquoi le développement d'IA piloté par les fondateurs et le petit studio d'IA l'emportent sur l'échelle : goût, appropriation, vitesse, et la discipline de dire non.
Par Vitor Lima
La chose la plus honnête que l'on puisse dire de la plupart des produits d'IA, c'est que personne n'en était vraiment responsable. On le sent dans les coutures : une zone de chat vissée sur un tableau de bord, un bouton « résumer » qui produit les quatre mêmes phrases fades quoi que vous lui donniez, une page de paramètres avec onze interrupteurs de modèles qu'un chef de produit a réussi à imposer. Ce ne sont pas des produits qui ont perdu face à un concurrent. Ils ont perdu face à leur propre organigramme. Voici le plaidoyer pour le petit studio d'IA — pour le développement d'IA piloté par les fondateurs comme choix délibéré, et non comme une phase dont on sort.
Nous construisons des applications d'IA pour gagner notre vie, en studio de deux personnes. Ce n'est pas une contrainte dont nous nous excusons. C'est la raison pour laquelle le travail est bon. Ce qui suit n'est pas de la nostalgie pour les startups de garage. C'est une affirmation sur l'endroit où les produits d'IA cassent et sur qui est le mieux placé pour les empêcher de casser.
Le goût est un avantage de petite équipe, et l'IA l'a amplifié
Avant les modèles génératifs, le goût dans le logiciel se résumait surtout à la mise en page et au texte. On pouvait livrer quelque chose de simplement correct et les utilisateurs s'adaptaient. L'IA a changé les enjeux parce que la sortie du modèle est la surface du produit. Quand votre application écrit, suggère, résume ou décide, des milliers de menus arbitrages fuitent directement vers l'utilisateur : le ton, la longueur, quand rester silencieux, quand admettre l'incertitude, et même à quoi ressemble une « bonne » réponse pour cette personne, à cet instant.
Ces arbitrages ne survivent pas à un comité. Ils sont moyennés jusqu'à devenir de la bouillie.
Avec Youp, notre application de journal intime dopée à l'IA, le travail le plus difficile n'a jamais été la plomberie du modèle. C'était de décider ce que l'application ne devait pas dire. Un compagnon de journal qui répond à une entrée difficile par une positivité guillerette est pire qu'un compagnon qui ne dit rien. Nous avons donc consacré notre effort à la retenue : la longueur des réponses, le moment où une réflexion doit tenir en une seule phrase calme, le moment où le bon geste est de ne rien demander du tout. C'est une décision de goût, et elle ne reste cohérente que parce qu'une ou deux personnes tenaient l'ensemble dans leur tête et étaient prêtes à défendre un « non ».
À retenir : Pour les produits d'IA, le goût n'est pas de la décoration. C'est la spécification. Si la personne qui a le goût se trouve à trois niveaux du prompt, du flux de jetons et de l'état vide, son goût n'atteint jamais l'utilisateur. Dans un petit studio, la distance est nulle.
Appropriation : celui qui a choisi le modèle répond aussi au ticket
Les grandes équipes sont organisées pour diviser la responsabilité, ce qui est exactement la mauvaise forme pour des systèmes qui échouent de façon floue et transversale. Un champ halluciné, un pic de latence sous charge, une étape de récupération qui ne renvoie discrètement rien — aucun de ces cas ne respecte les frontières d'équipe. Ils vivent dans l'interstice entre « l'équipe modèle », « l'équipe plateforme » et « l'équipe application ». Les interstices, c'est là où personne ne ressent la douleur.
MadaiOps, notre application d'ordres crypto et d'opérations de trading, rend cela concret. Elle passe, achemine et surveille des ordres sur plusieurs plateformes d'échange en temps réel. Le taux de défaillance tolérable pour « mon ordre est-il vraiment passé » est à peu près nul. On ne peut pas construire cela avec une appropriation diffuse, car la fiabilité n'est pas une fonctionnalité que l'on ajoute. Ce sont mille décisions défensives sur les nouvelles tentatives, l'idempotence, les exécutions partielles, et ce qu'il faut montrer à un utilisateur quand une plateforme d'échange ment sur son propre état. La personne qui écrit la logique de routage doit être la même que celle qui ressent l'angoisse d'un ordre bloqué à trois heures du matin. Quand ce sont des personnes différentes, la couture entre elles devient la panne.
À retenir : Livrez l'organigramme et vous livrez ses coutures. Un studio où les mêmes mains touchent le prompt, la logique de nouvelle tentative et le canal d'incident produit des systèmes qui échouent moins et récupèrent plus vite — non parce que les gens sont plus intelligents, mais parce qu'aucune responsabilité ne tombe dans un interstice.
La vitesse est réelle, mais l'intéressant est le type de vitesse
Tout le monde prétend que les petites équipes vont vite. La version paresseuse de cette affirmation est vraie et ennuyeuse : moins de réunions, pas de chaînes d'approbation. La version intéressante, c'est que le développement d'IA récompense un tempo précis que les grandes équipes ne peuvent structurellement pas égaler.
Construire avec des modèles est empirique. Vous ne savez pas comment se comporte un prompt, une fenêtre de contexte ou une boucle d'utilisation d'outils tant que vous ne l'avez pas exécuté contre de vraies entrées. La boucle centrale est : formuler une hypothèse, changer une seule chose, observer les vraies sorties, réviser son modèle mental. Les équipes qui gagnent exécutent cette boucle plusieurs fois par jour avec le véritable décideur aux commandes.
Une grande organisation transforme chaque itération en ticket, en sprint, en revue. Le temps que le retour arrive, la personne qui avait l'hypothèse a perdu le fil. Un studio comprime le délai hypothèse-observation à quelques minutes. C'est pourquoi nos premiers travaux sur Linea — automatisation de flux de travail native de l'IA, actuellement en bêta privée — sont restés dans une boucle de prototypage serrée plutôt que dans une feuille de route. Le comportement des agents est trop émergent pour être planifié sur un diagramme de Gantt. On le construit, on le regarde faire quelque chose de bête, et on corrige le raisonnement, encore et encore, sans transmissions qui grignotent la boucle.
Le compromis, énoncé honnêtement
Ce type de vitesse a un coût réel. Elle ne passe pas à l'échelle en ajoutant des gens, et elle dépend du fait que quelques individus restent profondément immergés dans le contexte. C'est un risque véritable, et prétendre le contraire serait malhonnête. Nous l'acceptons parce que, pour les produits d'IA, l'alternative — un processus qui survit au renouvellement des équipes mais dilue le jugement — produit un moins bon logiciel. Nous préférons être petits et cohérents que grands et moyennés.
Dire non, c'est toute la discipline
La pathologie qui définit les produits d'IA en ce moment est l'incapacité à dire non. Chaque modèle peut faire un peu de tout, alors chaque feuille de route enfle jusqu'à tout inclure. Le résultat, ce sont des produits larges, superficiels et oubliables : une liste de fonctionnalités là où devrait se trouver un point de vue.
Le levier d'un petit studio, c'est le « non » crédible. Non aux interrupteurs de modèles que la plupart des utilisateurs ne peuvent pas appréhender. Non à un chatbot dans un produit qui ne devrait pas en avoir. Non à livrer une capacité que nous ne pouvons pas rendre fiable, car une fonctionnalité d'IA capricieuse est pire que pas de fonctionnalité. Elle apprend aux utilisateurs à ne pas vous faire confiance, et cette confiance ne revient pas. Ce n'est pas de l'ascétisme. C'est la reconnaissance que, dans les produits d'IA, la surface d'exposition est un passif. Chaque capacité que vous exposez est une promesse de qualité que vous devez désormais tenir sur un espace d'entrées illimité.
À retenir : L'artefact le plus précieux qu'un petit studio produit est souvent la liste des choses qu'il a refusé de construire. Cette liste est la colonne vertébrale du produit. Les grandes équipes peinent à en tenir une, car dire non à une capacité revient généralement à dire non à un collègue — une conversation plus difficile que de livrer la version médiocre.
Ce que cela ne veut pas dire
Il serait facile de conclure sur « petit, c'est bien, grand, c'est mal ». Certaines choses ont réellement besoin d'échelle : l'entraînement de modèles de pointe, l'infrastructure à l'échelle planétaire, les domaines réglementés où les effectifs achètent des pistes d'audit et une défendabilité juridique. Un studio n'est pas la bonne forme pour cela, et nous ne prétendons pas l'être.
Mais la couche dans laquelle nous travaillons — concevoir et livrer des applications par-dessus des modèles qui existent déjà — est précisément l'endroit où l'échelle cesse d'aider et commence à diluer. Le goulot d'étranglement, là, n'est ni le calcul ni les effectifs. C'est un jugement cohérent appliqué sans relâche à mille petites décisions, tenu par des gens assez proches du travail pour ressentir chacune d'elles.
Voilà tout le plaidoyer. Non pas que nous soyons moins chers ou plus débrouillards, mais que le médium récompense la concentration du jugement, et qu'un petit studio piloté par ses fondateurs est la forme la plus concentrée que le jugement puisse prendre. Quand le modèle peut tout faire, la chose rare, c'est quelqu'un qui décide — avec du goût, et engagé sur le résultat — ce qu'il doit faire, et plus souvent encore, ce qu'il ne doit pas faire.