Les projets ne sont pas simplement une collection de tâches : l’IA actuelle se heurte toujours à un goulot d’étranglement majeur dans l’automatisation des tâches complexes : si l’IA peut gérer des tâches individuelles, elle peine à gérer un projet dans son ensemble. L'auteur @snewmanpv, fondateur de Google Docs, s'appuie sur le génie logiciel pour souligner que, dans la gestion de projet, « le tout est plus que la somme de ses parties » et remet en question la notion de « délais de développement à court terme pour l'IA générale » – selon laquelle, une fois maîtrisée les tâches mensuelles, l'IA pourrait facilement s'adapter à des tâches scolaires. À travers son expérience personnelle et une analyse logique, l'auteur dissèque objectivement les lacunes de l'IA, nous incitant à ne pas surestimer la vitesse à laquelle elle les comble. Argument clé : les projets ne sont pas des « briques Lego » pour les tâches. L'auteur commence par souligner que, lors de l'évaluation des capacités de l'IA, on a souvent tendance à décomposer les tâches en « listes de tâches » (comme le codage et le débogage), mais cette approche est simpliste. En réalité, les frontières entre les tâches sont floues et l'information « s'infiltre » : lors de la réalisation d'une sous-tâche, on ne se contente pas de produire du code, mais on acquiert également de nouvelles connaissances sur les problèmes, les bases de code ou les données. Ces « sous-produits » peuvent être exploités dans les tâches suivantes, entraînant des ajustements de la stratégie globale. Si les sous-tâches sont assignées à des agents d'IA indépendants et que leurs « souvenirs » sont effacés une fois terminées, cette chaîne d'apprentissage est rompue, ce qui rend difficile la progression cohérente de l'IA. L'auteur cite les radiologues en exemple : ils interprètent des images, mais communiquent aussi avec les patients et leurs collègues – des activités difficiles à dissocier. De même, en génie logiciel, la gestion de projet repose sur des compétences de haut niveau telles que l'adaptation continue et la vision transversale, rarement mentionnées dans les listes de tâches, mais essentielles à la réussite. Études de cas comparatives : Le passage des petits projets aux projets colossaux Pour illustrer son propos, l’auteur partage deux expériences qui mettent en lumière les changements qualitatifs induits par l’échelle : • Petit projet : prototype Writely (environ 1 personne-année) En 2005, l'auteur et deux associés ont finalisé Writely, précurseur de Google Docs, en quatre mois. Ce fut un processus improvisé : mise en place rapide des serveurs, de l'interface utilisateur et des mécanismes de synchronisation, résolution des problèmes au fur et à mesure. Le système était intuitif et ne nécessitait aucune planification à long terme, reposant davantage sur l'intuition et la réactivité. Malgré quelques difficultés techniques (comme la compatibilité avec les navigateurs), le processus global s'est apparenté à un simple échauffement, sans outils spécifiques ni expérience préalable. • Projet d'envergure : Système Scalyr (environ 100 années-personnes) À partir de 2011, l'auteur a dirigé une équipe de plusieurs dizaines de personnes et a consacré dix ans à la création de Scalyr, une plateforme d'analyse de journaux permettant de diagnostiquer les pannes dans les applications web complexes. Ce projet a nécessité l'acquisition de compétences entièrement nouvelles : • Résolution systémique des problèmes : au lieu de corriger les bogues un par un, elle consiste à identifier les schémas et à éliminer des catégories entières de problèmes en une seule fois (comme les défaillances de coordination des serveurs). Cela repose sur des années d’expérience et de discernement. Planification stratégique : Face à des crises telles que l’attrition client en cours de projet, l’équipe doit réorienter sa stratégie : évaluer l’architecture, décomposer les étapes, valider les hypothèses et rectifier le tir au plus tôt. Il s’agit de diriger un orchestre symphonique, et non de jouer en solo. • Diagnostic des performances : Lors de la distribution instantanée des tâches sur des milliers de serveurs, il est nécessaire de sélectionner avec soin les points de données clés à surveiller afin d'éviter une surcharge d'informations. L'auteur souligne que les compétences des agents dans les petits projets (comme la décomposition des tâches et la correction des erreurs) échouent souvent, voire deviennent des obstacles, dans les grands projets. L'« improvisation » de Writely peut se transformer en désastre dans Scalyr. Le « seuil de mise à niveau » de l'IA : des compétences cognitives au-delà du paradigme actuel. Cet article emprunte au concept managérial « Ce qui vous a permis d'arriver là où vous êtes ne vous permettra pas d'aller plus loin » pour démontrer que la progression de l'IA n'est pas linéaire. L'IA actuelle (comme Claude Code) excelle dans les tâches à court terme, mais son déploiement sur des projets de grande envergure exige une « cognition profonde ». • Gestion du contexte : Les grands projets génèrent une quantité massive de détails, et l’IA doit filtrer les informations pertinentes au lieu de s’y noyer. • Apprentissage et adaptation continus : les ingénieurs seniors « personnalisent » leurs compétences, optimisent le code et leurs habitudes de débogage pour résoudre les problèmes des projets ; ce type d’accumulation est difficile à simuler avec la formation « ponctuelle » de l’IA. Métacognition : au-delà de l’exécution, il s’agit aussi de réfléchir aux processus, d’anticiper les goulots d’étranglement et d’améliorer les méthodes. L’auteur cite les observations du chercheur en IA Nathan Lambert : les chaînes de formation modernes sont passées d’étapes simples à des réseaux complexes impliquant la coordination de plusieurs équipes, ce qui exige un leadership capable d’« anticiper les risques ». Ces compétences ne relèvent pas d'« agents intelligents à usage général », mais sont plutôt spécifiques à un domaine et affinées par l'expérience. Lorsqu'une IA maîtrise un projet d'un an, atteindre une échelle de 100 années-personnes reste encore un objectif lointain. Conclusion et implications : l’automatisation doit attendre un « leader de l’IA » L'auteur réaffirme que les projets de génie logiciel à fort impact (comme l'évolution de Google Docs) débutent souvent modestement, mais nécessitent des investissements massifs. L'automatisation des tâches n'est qu'un point de départ ; l'automatisation complète exige que l'IA puisse piloter de manière autonome un projet mobilisant 100 personnes-années. Ceci remet en question l'image optimiste de « capacités d'IA en pleine croissance et sur le point d'exploser » : l'expérience historique montre que les progrès significatifs requièrent des investissements en R&D entièrement nouveaux, et non une simple mise à l'échelle. Adresse de l'article
