Entire lance une forge Git où des agents évaluent les changements avant leur validation

Les agents écrivent du code. Entire veut organiser ce qui se passe ensuite. L’éditeur a ouvert sa forge Git le 26 octobre autour d’un objet de travail nommé Trail. Celui-ci rassemble les évaluations automatiques et les éléments nécessaires à la validation d’un changement. L’annonce concerne un service et des outils documentés. Elle ne se limite pas à une nouvelle levée de fonds.

Trails réunit les résultats au lieu d’allonger seulement les commentaires

Dans la présentation du fonctionnement, chaque envoi de code peut déclencher plusieurs agents de relecture. Ils produisent une note et une justification. Entire présente notamment des évaluations de sécurité et de qualité du code. Une autre peut indiquer si une relecture humaine reste nécessaire. Les derniers passages permettent de suivre l’évolution des résultats au fil des corrections.

Les agents peuvent signaler des problèmes précis et proposer des corrections. Ces éléments restent visibles tant qu’ils sont ouverts. Les équipes peuvent aussi définir des conditions de fusion au niveau du dépôt. Ces règles appelées Gates peuvent inclure une approbation humaine et la réussite de contrôles techniques. Le fonctionnement dépend donc des exigences effectivement configurées par l’équipe.

Les tests restent un contrôle distinct

La documentation des intégrations CI décrit un aperçu public avec Buildkite et Depot. Le fournisseur connecté récupère le code et exécute les commandes de construction ou les tests configurés. Entire reçoit les résultats et les affiche dans le Trail. Les commandes et la configuration du pipeline restent chez le fournisseur de CI.

Un résultat doit correspondre à la dernière modification

Les contrôles obligatoires sont évalués sur le dernier commit. Un résultat réussi sur une version antérieure ne suffit donc pas pour fusionner une nouvelle modification. La documentation signale une exception pour les commits envoyés avant la connexion du module. Installer une intégration et définir les contrôles requis sont ainsi deux étapes différentes. Un indicateur favorable produit par un agent ne remplace pas automatiquement un test de fonctionnement.

Le code et la mémoire des agents se rapprochent

Entire ajoute une mémoire continue qui conserve des sessions et des demandes dans l’historique du dépôt. L’objectif annoncé est de rendre les décisions passées retrouvables par les agents. Deux composants servent à cartographier le code et à relier cette carte aux sessions précédentes. Cette mémoire est présentée comme un moyen de conserver le contexte du travail entre plusieurs sessions.

L’annonce ouvre l’hébergement natif de dépôts privés. Les dépôts publics et l’hébergement autonome de nœuds Git figurent encore dans la feuille de route. La documentation des dépôts distingue aussi deux situations. Un miroir peut conserver GitHub comme source principale. Un dépôt hébergé directement sur Entire utilise son propre réseau. Cette différence détermine notamment où passent les écritures.

Le choix d’une région pour le dépôt ne décrit pas à lui seul tout le traitement. Entire explique que ses agents de relecture travaillent dans des environnements cloud isolés. Avant d’y confier un projet, une équipe doit donc examiner les accès au code et aux sessions ainsi que les conditions du service. L’annonce d’ouverture ne promet pas un usage gratuit ou illimité de tous les composants.

L’enjeu reste la qualité du changement accepté

Je trouve cette évolution intéressante parce qu’elle rend la validation plus visible. Ça ne donne pas une preuve automatique que le logiciel fonctionne. La question reste ce que les contrôles vérifient et qui assume la décision finale. Notre article sur l’enquête de la Linux Foundation éclaire déjà la charge de relecture créée par les contributions assistées par IA. Entire propose une organisation de cette étape. Son efficacité devra être appréciée sur le travail réellement livré.