Les bonnes contraintes ont façonné les meilleures époques du logiciel et ma propre carrière. Quelques approches bien tranchées, comme les principes de l'application 12-facteurs ou le MVC, nous ont donné un langage commun pour construire des services fiables et concevoir la séparation des préoccupations. C'était des règles simples, faciles à énoncer, difficiles à suivre parfaitement. Elles ont donné naissance à des industries entières : le SaaS, le PaaS, l'infrastructure cloud. Tout cela s'est bâti sur des contraintes bien pensées qui disaient aux constructeurs : voici la limite, restez dans cette limite, et de bonnes choses suivront. J'ai personnellement bénéficié de l'application de ces contraintes dans certains de mes meilleurs travaux.
Je crois que les logiciels natifs de l'IA ont besoin de leur propre contrainte. Voici celle que j'ai imaginée.
Votre code source a une taille maximale. Ce n'est pas une question de goût. La limite est réelle, mesurable, et plus petite que vous ne le pensez.
La limite : la moitié de la fenêtre de contexte du modèle d'IA que vos agents utilisent pour construire et maintenir votre produit. Cela signifie que la taille de votre logique métier principale et de votre contexte système ne doit pas dépasser la moitié de la fenêtre de contexte du LLM sur lequel vous vous appuyez.
Pourquoi la moitié ? La fenêtre de contexte sert deux objectifs. La première moitié contient votre code. La seconde moitié est là où l'agent raisonne, planifie et génère. Remplissez toute la fenêtre avec du code et vous ne laissez aucun espace pour la réflexion. La moitié pour la compréhension. La moitié pour la cognition.
La partie la plus difficile des entreprises de logiciels n'a jamais été de construire des fonctionnalités.
Chaque fondateur tech expérimenté le sait. La partie difficile était d'identifier le plus petit logiciel utile pour un segment de clients suffisamment large, puis de rallier les gens autour du travail difficile d'acquisition de clients, de service client et de fidélisation.
Construire des logiciels coûtait cher. Les ingénieurs coûtaient beaucoup. Cela créait des frictions, donnant naissance à des processus de développement itératifs, mais cela imposait aussi une discipline. Vous deviez choisir : de quoi les clients ont-ils le plus besoin ? Quelle est la plus petite chose qui vaille la peine d'être construite ? Le coût humain de l'ingénierie maintenait les équipes concentrées. Les contraintes créaient de la clarté. Les meilleures entreprises de la Silicon Valley ont grandi ainsi.
Maintenant, les agents IA construisent presque tout ce que vous demandez. Le goulot d'étranglement a disparu. La discipline a disparu avec le goulot d'étranglement.
La production gratuite mène à la surproduction. La surproduction est le mode d'échec par défaut des entreprises natives de l'IA.
Les fondateurs et investisseurs non techniques doivent comprendre cela. Plus de fonctionnalités, plus de code, et plus de surface produit à maintenir ne sont plus des signes de progrès. Ils signalent une entreprise sans contraintes de haute qualité, et parfois, un manque fondamental de clarté.
La surproduction sans distribution et consommation évolutives crée une fuite massive dans la capture de valeur. Vous livrez dix fonctionnalités. Deux génèrent de la rétention. Les huit autres ajoutent de la complexité qui ralentit les deux qui comptent. Chaque ligne de code devient un passif déguisé en actif.
Les bâtisseurs expérimentés connaissent le point de bascule. Le code passe du service aux clients à son propre service. La complexité devient l'ennemie du produit. Les équipes passent plus de temps à gérer le logiciel qu'à améliorer l'expérience client. Le système commence à sembler lourd, les utilisateurs commencent à décrocher, et vos équipes en contact avec les clients deviennent silencieusement frustrées.
Dans l'ancien monde, vous atteigniez ce point de bascule en années. Dans le monde natif de l'IA, vous l'atteignez en semaines. Les agents ne se fatiguent jamais, ne se rebellent jamais, et ne disent jamais « c'est trop complexe, on devrait s'arrêter ».
Comment savoir quand s'arrêter ? Quand l'IA écrit du code illimité gratuitement, quel est le signal qui vous dit que c'est assez ?
C'est la règle de la demi-fenêtre.
Votre logique métier principale doit tenir dans la moitié de la fenêtre de contexte du modèle qui maintient votre code source. Mesurez votre code source en tokens. Comparez-le à la moitié de la fenêtre de contexte. Si vous êtes au-dessus, votre main-d'œuvre IA se dégrade déjà — pas visiblement, pas dramatiquement, mais silencieusement et régulièrement.
Le danger : rien ne se casse visiblement lorsque vous franchissez cette ligne. L'agent ne refuse pas. Le code semble correct. Les tests passent. Le bug que vous avez signalé est corrigé.
Mais l'agent opère désormais sans comprendre complètement votre système. L'agent fait des correspondances de motifs sur des fragments au lieu de raisonner sur l'ensemble. Des régressions subtiles apparaissent. La logique est dupliquée dans des parties du code source que l'agent ne peut pas voir. Les problèmes sont « résolus » en ajoutant du code là où le code existant aurait dû être modifié.
Vous ne le remarquerez pas immédiatement. La vélocité semble toujours élevée. Les pull requests continuent d'affluer. Chacune rend la suivante légèrement pire. La dégradation composée joue contre vous.
Au moment où vous demandez « pourquoi nos agents tournent-ils en rond ? », vous êtes déjà en plein problème.
Cette règle est une discipline commerciale sous un habit technique.
La simplicité devient votre avantage concurrentiel lorsque la production ne coûte rien. Construisez le plus petit code source qui apporte une réelle valeur à vos clients. Chaque fonctionnalité inutile, chaque abstraction superflue, et chaque ligne de code spéculatif mange le budget cognitif de votre main-d'œuvre IA. Finalement, ils mangent la capacité de votre entreprise à bouger.
Les meilleurs produits ont toujours été les plus simples qui résolvent complètement un vrai problème. La pénalité pour avoir violé ce principe arrive maintenant plus vite et se cumule plus fort. Vos agents IA ne vous repousseront pas comme l'aurait fait un ingénieur senior frustré.
La règle s'adapte à l'architecture. Startup mono-produit : elle s'applique à l'ensemble du code source. Entreprise multi-services : elle s'applique à chaque service indépendamment. Toute partie de votre système qui doit être comprise dans son ensemble doit tenir dans la limite où vos agents raisonnent sur l'image complète.
L'architecture de votre produit reflétera les limites cognitives de vos agents, que vous le planifiiez ou non. Les fondateurs qui conçoivent pour cela délibérément distanceront ceux qui apprennent par la douleur.
Il ne s'agit pas de perfection. Vous ne resterez pas toujours en dessous de la ligne. Les codes sources grandissent. Les fonctionnalités s'ajoutent. La complexité s'accumule. Le but est l'aspiration, pas la conformité rigide. Si vous gardez cette règle à l'esprit et restez proche de la limite, vous prendrez de meilleures décisions sur quoi construire, quoi diviser, et quoi supprimer. La contrainte vous donne un point de référence quand tout le reste dit « construisez plus ». Parfois, cela signifie repenser votre architecture de sous-agents pour s'adapter à la règle — très similaire à la façon dont les équipes humaines divisent la propriété en grandissant.
J'aspire à suivre cette règle dans mon propre travail. Non pas parce que la violer signifie un échec immédiat, mais parce que rester proche de cette contrainte m'aide à construire des logiciels qui restent utiles, maintenables et précieux dans le temps. Les fondateurs qui s'orientent autour de cela iront loin. Ceux qui ignorent complètement les contraintes apprendront par la douleur.
Les bonnes contraintes ne garantissent pas le succès. Elles rendent le succès plus probable en supprimant les façons les plus courantes d'échouer. L'application 12-facteurs était un ensemble de principes qui n'ont pas construit votre entreprise SaaS à votre place, mais si vous les suiviez, votre infrastructure fonctionnait quand vous aviez besoin de passer à l'échelle. La règle de la demi-fenêtre fonctionne exactement de la même manière. Suivez l'esprit. Restez proche de la limite. Construisez des entreprises de logiciels utiles qui durent.
La simplicité gagne toujours. Maintenant, la simplicité gagne plus vite.
À propos de l'auteur : Abhishek Parolkar est le PDG de https://brain.pe - qui aide les sociétés de capital-investissement à créer leurs cerveaux IA numériques pour leur propre entreprise ou pour des transactions spécifiques. Vous avez peut-être adopté l'IA, mais l'IA vous a-t-elle adopté ?
