Compte rendu de la présentation d’un « Studio de Forge » lors de la Troisième Journée Forgeons !
Cette journée qui mettait en avant le principe de la « Fonderie » comme « extension » de « Forge » dans le contexte de la « programmation automatique » (« vibecoding ») était également accompagnée d'un sous-titre pour le moins énigmatique : « Forges dans un monde d'IA : émergence des NéoForges ». Il serait à ce stade parfaitement compréhensible que le lecteur soit pour le moins dérangé par ce néologisme quelque peu racoleur; mais cet effet d'annonce accrocheur reflète pourtant un phénomène réel au moment où s'engage « une course poursuite pour remplacer GitHub ».
Comme rappelé dans le texte d'introduction consacré aux « Fonderies », les Agents continuent de mettre sous pression l'univers de Forges et leurs utilisateurs. Après une première vague de disruption frôlant parfois le véritable « déni de service » — ayant nécessité la création du projet Anubis entre autres — ce sont à présent les « Agents de code » qui sont en train d'ébranler le fondement des infrastructures telles qu'elles se sont consolidées au cours de la dernière décennie : disruption des services de la plateforme GitHub et déluges de demandes d'ajouts pour ne citer que ces quelques exemples, font partie de ces phénomènes qui traduisent ce moment critique dans l'histoire des Forges.
Constatant qu'une nouvelle génération de plateformes de développement adaptée à la « programmation automatique » était en train d'émerger, le terme « NéoForge » s'est donc imposé comme une première tentative de décrire un phénomène émergent.
Après cette brève introduction très spéculative sur le phénomène des « NéoForges », les discussions ont pu se recentrer sur des questions qui touchent plus directement à la disruption des Agents de code. Après avoir dressé un bref état des lieux concernant la position de grands projets open-source au sujet de la « programmation automatique » — par exemple ceux de Linux, Debian, et Blender — et la choix de « banir » le vibecoding dans le cas de Codeberg, la discussion s'est ensuite engagée pour reconnaitre que les Forges ne se limitaient pas à des aspects purement techniques.
Deux interventions en particulier ont permis de dépasser la simple question de l'automatisation de la programmation en ouvrant le débat sur les composantes « sociales » des Forges. Dans un premier cas, les aspects de gouvernance associés aux Forges (Codeberg et Forgejo dans ce contexte) font l'objet d'une recherche post-doctorale et montrent que la « structure sociale » de ce type de plateforme est un aspect central dans ce genre de démarche et dépasse largement les aspects purement techniques.
À ce titre, le cas de Codeberg, par exemple dans les polémiques autour du banissement de la programmation automatique, ont fait l'objet de discussions « contradictoires » où des questions de transparence notamment ont été interrogées dans une mise en comparaison avec la posture radicalement transparente dans le cas de Gitlab et son manuel de l'entreprise dématérialisée.
Dans un échange faisant suite à ces remarques, il a été ensuite rappelé que les aspects « organisationnels » des Forges ne se limitaient pas aux seuls outils de communication et de collaboration mais qu'ils bénéficiaient égalemment des « schémas organisationels » et des bonnes pratiques portés par le système Git lui-même (tronc, branches, contributeurs, etc.) faisant des Forges des outils puissants au service de projets construits collectivement et constituant potentiellement des écosystèmes économiques.
De retour sur les questions de l'automatisation du code, un consensus semblait clairement reconnaître les effets délétères du vibecoding sur les écosystèmes libres. Il fut rappelé dans ce contexte que le slogan « Forges pour les Humains, Usines (ou Fonderie) pour les IA » résonnait avec ce constat, et militait au final pour une forme de distinction qui pourrait, éventuellement, contribuer à préserver les communautés de contributeurs.
En préambule à la présentation d'un prototype de « Studio » en tant que « surcouche » d'une Fonderie, il a été rappelé que le principe de « Forge métier » était au cœur de l'initiative « Forgeons ! ». Ces Forges spécialisées qui concernent des domaines non informatiques (Forges éducatives, légales, éditoriales, de conception) s'adressant à des utilisateurs non-informaticiens, abordent nécessairement la question de la génération automatique de code avec plus d'intérêt.
Dans le cas d'un prototype de « Studio de Forge » pour le projet BIMR, les utilisateurs concernés sont des architectes (dans le sens de la construction), des ingénieurs ou des urbanistes. Ce prototype permettant de concevoir des projets en générant du code source Python, il s'agit dans ce cas d'une pratique identifiée dans la littérature scientifique comme relevant de la « programmation utilisateur » (user programming). Il fut rappelé que l'« invention » des langages de script ou des environnements de programmation visuelle visait à offrir à des non-spécialistes la capacité d'adapter leurs environnements numériques ; on pourrait donc voir dans la génération automatique de code une forme de continuité.
La présentation du prototype de « Studio de Forge » fut une occasion de découvrir et discuter de plusieurs principes novateurs. En premier lieu, il s'agit ici d'une terminologie qui cherche à décrire un nouveau type d'interface utilisateur, un « Studio » qui vient se positionner en surcouche d'une « Fonderie » entendue comme une « Usine » logicielle opérant à partir d'une « Forge ».
Le principe de « Studio » fait référence aux environnements de type « générateur d’application » tels que Lovable, Manus et consorts, qui sont des Agents de code spécialisés dans la génération d'applications web notamment. Une première itération du prototype réalisé à l'IGN et à l'Assemblée nationale, développé en tant que « Tablette » était basée sur un dorsal (backend) Python et livrait l'« application générative » par l'intermédiaire d'une iframe à proximité de la zone de discussion.
Dans cette nouvelle expérimentation, il s'agit de montrer comment un « Studio de Forge » peut mobiliser une Forge en tant que backend applicatif. Dans le cas présent, « Studio » se présente donc comme une application web « sans tête » connectant deux flux serveurs, l'un pour l'inférence LLM par l'intermédiaire d'OpenRouter, et l'autre pour le stockage de code et sa génération par l'intermédiaire de Forgejo.
Les potentialités d'un « Studio de Forge » restent à être imaginées. À titre d'exemple, le prototype montre à travers un mode d'« exploration » la possibilité de structurer les contenus d'une Forge par le biais d'un fichier de configuration.