Un PRD en entrée, du code fusionné en sortie : déployer une usine logicielle 24h/24 sur GPT-6 Astra

Une nouvelle vague de modèles phares a relancé le débat sur l'AGI, et cette section s'ouvre sur sa version la plus bruyante : une citation d'un dirigeant déclarant que l'intelligence générale est arrivée. L'hôte reste sceptique face au slogan, mais rapporte un vrai changement issu d'essais pratiques — le modèle saisit l'intention avec moins d'allers-retours et fait moins d'hypothèses étranges qui pénalisaient ses prédécesseurs.

Sur le papier, les deux modèles de tête semblent à égalité, les scores publics pointant dans la même direction. La semaine de tests comparatifs de l'auteur raconte une autre histoire, le nouveau venu l'emportant dans la majorité des exécutions. Cet écart entre scores ex æquo et expérience vécue mérite d'être nommé honnêtement : c'est la charge de travail d'une seule personne, pas une mesure répliquée, et il faut le lire ainsi jusqu'à ce que quelqu'un refasse l'exercice.

L'idée centrale porte un nom mémorable : l'usine logicielle, aussi appelée usine noire. Une spécification produit ou une issue entre, et du code relu et livrable sort, avec le triage, la planification, l'implémentation, la validation et la revue gérés comme un pipeline. Plus tôt cette année, cette promesse paraissait irréaliste ; l'auteur affirme que des modèles plus puissants et un harnais plus robuste l'ont fait passer du fantasme à quelque chose qui mérite l'expérimentation — tout en admettant que ce n'est de loin pas encore totalement fiable.

Le modèle de déploiement compte plus que la métaphore. Au lieu d'une expérience sur un ordinateur portable, l'usine vit sur une machine distante qui tourne jour et nuit et accepte du nouveau travail à toute heure. L'entrée est toujours la même — une issue décrivant ce qu'il faut construire — et la sortie est toujours la même : une pull request relue qui fusionne elle-même ou escalade vers un humain. La vision affichée est que chaque individu et chaque entreprise finira par faire tourner une telle chaîne dans le cloud.

Le démarrage est délibérément sans cérémonie : pointer un agent de codage vers le dépôt de l'usine, coller le prompt d'installation fourni et répondre à ses questions d'entretien. Le flux couvre les deux directions — une base de code neuve qui commence sa vie comme spécification écrite d'un produit minimum viable, et une base de code existante sur laquelle l'usine vient se greffer. Tester d'abord en local est l'habitude recommandée ; le déploiement distant est la destination.

Pour la démo en direct, l'hôte choisit un hébergement virtuel basé sur KVM et désigne l'offre milieu de gamme KVM2 comme suffisante, tout en soulignant que n'importe quelle machine Ubuntu dans le cloud ferait l'affaire. Le contexte commercial a aussi sa place dans le résumé : le segment hébergement est sponsorisé et s'accompagne d'un code de réduction personnel, donc la recommandation spécifique du fournisseur doit être lue avec cet intérêt à l'esprit.

La procédure d'installation s'appuie sur l'agent de codage pour presque tout. L'agent vérifie les outils locaux, demande quel serveur virtuel est la cible, dans quel dépôt l'usine doit travailler et quel agent doit la propulser — les deux options testées étant Claude Code et Codex. Pour la démo, l'hôte pilote depuis un agent local familier tandis que l'usine elle-même tourne sur Codex associé au nouveau modèle, appliqué à une petite application de raccourcissement de liens préconstruite pour aller vite.

Le plugin d'hébergement est l'élément qui rend la configuration distante facile. Une commande d'installation plus une connexion via navigateur donnent à l'agent le contrôle du compte : il liste les instances, récupère l'identifiant de la VM et l'adresse publique, puis procède à l'accès SSH, aux règles de pare-feu et aux installations d'applications. Les limites sont énoncées clairement — le plugin ne peut pas créer de serveur par lui-même, la machine doit donc déjà exister avant que l'agent ne prenne le relais.

Vient ensuite l'étape qu'aucun agent ne peut franchir à votre place : les identifiants. L'hôte ouvre un shell sur le serveur tout neuf, le relie à GitHub avec un code d'appareil, et connecte l'agent distant de la même manière, après avoir activé l'autorisation par code d'appareil dans les paramètres de sécurité du compte de chat. Une commande de salutation d'une ligne adressée au nouveau modèle sert de test de fumée — une réponse signifie que le côté distant dispose de connexions fonctionnelles pour l'hébergement de code et l'inférence.

À partir de là, l'installation prend de l'ordre de huit minutes : l'usine elle-même, le moteur de workflow Archon en dessous, la copie du dépôt et la configuration. L'agent pose ensuite des questions opérationnelles — nom d'hôte, port — et propose une première issue d'essai tirée de la liste de tâches du projet. Cette issue est déposée depuis la ligne de commande, triée selon les règles de l'usine, classée et menée jusqu'à une pull request validée, les réglages de domaine étant gérés par le même plugin d'hébergement. Une fois la boucle confirmée, la session locale se ferme et la chaîne reste en marche, attendant la prochaine issue — étiquetée ouvertement alpha précoce, encore en cours de raffinement.