Transférer un projet de Codex vers Hermes sur un serveur

Pour obtenir de l’aide sur l’utilisation du service, consultez la documentation Ailoot.

Quel projet préparer avant un transfert de Codex vers Hermes ?#

Un dépôt est un dossier de projet qui contient l’historique de ses modifications Git. Une copie de travail contient les fichiers que vous modifiez. L’objectif ici est de transférer cette copie sur le serveur et de poursuivre le développement. Vous n’avez pas encore besoin de rendre l’application accessible aux visiteurs.

Si l’agent n’est pas encore installé sur le serveur, commencez par installer Hermes Agent sur un VPS. Ici, vous aurez besoin d’une installation fonctionnelle de Hermes, du terminal du serveur et de Git. Il vous faut un dépôt distant accessible depuis le serveur. Si vous n’en avez pas encore, créez-en un et enregistrez-y d’abord le projet sans secrets. Pour un dépôt privé, configurez à l’avance l’accès en lecture depuis votre propre compte ; ne placez pas de jeton dans l’URL du dépôt ni dans un message à l’agent.

Mettez en pause les modifications parallèles du projet pendant le transfert. Sur l’ordinateur source, ouvrez un terminal directement dans le dossier du projet et exécutez :

git status --short --branch
git status --short --ignored

La première commande affiche la branche et l’état des fichiers. M indique une modification et ?? un fichier que Git ne suit pas encore. Dans la deuxième commande, les fichiers ignorés sont marqués !!. Un état normal et propre ne prouve pas qu’aucun fichier nécessaire ne se trouve en dehors de Git.

Enregistrez les modifications nécessaires dans un commit distinct et poussez la bonne branche vers votre dépôt distant comme vous le faites habituellement. Avant le push, vérifiez le contenu du commit : il ne doit contenir ni clés, ni mots de passe, ni données réelles d’utilisateurs. Si vous ne savez pas quelles modifications enregistrer, demandez d’abord à Codex de les répertorier et d’en expliquer l’objectif, sans supprimer de fichiers ni pousser quoi que ce soit dans le dépôt.

Ne partez pas du principe que le clonage du dépôt transférera une base de données externe, le contenu d’un dossier ignoré ou vos conversations avec Codex. L’historique des conversations, les abonnements, les profils et les paramètres propres aux agents ne font pas partie de cette méthode de transfert.

Copier la bonne branche sur le serveur#

Commencez par enregistrer sur l’ordinateur source la sortie de cette commande :

git status --porcelain=v2 --branch

La ligne # branch.oid indique le commit actuel, et # branch.head la branche. Un commit est une version enregistrée du projet. Pour un projet habituel qui possède déjà des commits, cela vous permet de comparer la copie source et la nouvelle copie ; cette comparaison ne vérifie pas les modifications non enregistrées.

Sur le serveur, accédez au répertoire où vous stockerez vos projets. Clonez votre dépôt dans un nouveau dossier. Dans le modèle ci-dessous, remplacez REPOSITORY_URL par l’URL de votre dépôt, BRANCH_NAME par le nom de la branche que vous avez enregistrée et poussée, et my-project par le nom que vous souhaitez donner au nouveau dossier :

git clone --branch BRANCH_NAME REPOSITORY_URL my-project
cd my-project
git status --porcelain=v2 --branch

Il s’agit d’un modèle, pas d’une URL prête à copier. git clone crée un dossier et une copie de travail de la branche sélectionnée. Si le dossier de destination existe déjà, il doit être vide : ne supprimez pas son contenu pour relancer la commande ; choisissez un nouveau nom.

Comparez # branch.oid dans les deux copies. Si les valeurs diffèrent, ne commencez pas à corriger le code sur le serveur : vérifiez la branche sélectionnée, les commits que vous avez poussés et l’éventualité de modifications parallèles. Si la sortie d’état indique des fichiers modifiés, examinez-les séparément. N’utilisez ni nettoyage ni réinitialisation forcée pour « les faire correspondre ».

Les dépôts qui contiennent des sous-modules Git — des dépôts imbriqués — nécessitent également d’en récupérer le contenu. git clone propose l’option --recurse-submodules pour cela ; utilisez-la si le projet contient réellement des sous-modules et que leurs URL ont été vérifiées. Les projets comportant d’autres ressources externes peuvent nécessiter une procédure supplémentaire décrite dans le README.

Restaurer les dépendances conformément aux règles du projet#

Lisez d’abord le README et les fichiers de configuration du projet. Déterminez la version du runtime requise et le gestionnaire de paquets utilisé pour installer les dépendances. Ne remplacez pas l’outil habituel du projet par npm simplement parce qu’il apparaît dans l’exemple ci-dessous.

Exemple hypothétique avec Node.js et npm : le dépôt contient des fichiers package.json et package-lock.json cohérents, et une version de Node.js adaptée au projet est installée sur le serveur. Dans ce cas, exécutez la commande suivante dans le dossier du projet :

npm ci

Selon la documentation de npm ci, cette commande installe les dépendances de l’ensemble du projet à partir du fichier de verrouillage sans réécrire package.json ni package-lock.json. Si leur contenu n’est pas cohérent, l’installation échoue. Tout dossier node_modules déjà présent est supprimé avant l’installation.

Si le fichier de verrouillage a été créé avec des options qui influent sur l’arbre des dépendances, comme --legacy-peer-deps, npm ci doit recevoir les mêmes options. Vérifiez les instructions et les paramètres du projet source. Ne supprimez pas le fichier de verrouillage et ne mettez pas à jour toutes les dépendances pour masquer la première erreur de transfert.

Avant l’installation, vérifiez les commandes d’installation et de démarrage de votre projet. Exécutez-les dans une copie de travail distincte, sans accès aux données de production, et configurez les variables d’environnement nécessaires en dehors du chat et de Git. Si possible, utilisez des identifiants de test aux autorisations limitées pour vérifier le projet. Si le projet dépend d’une base de données ou de fichiers, restaurez d’abord un jeu de données de test autorisé conformément à ses instructions ; des fichiers source identiques ne remplacent pas ces données.

Après l’installation, exécutez les vérifications existantes indiquées dans le README : les tests et une compilation, si le projet en prévoit une. Les noms des commandes dépendent du projet. L’installation réussie des dépendances ne signifie pas encore que l’application fonctionne.

Ouvrir la copie de travail dans Hermes#

Dans le terminal du serveur, accédez à la racine de la nouvelle copie et démarrez l’agent déjà installé :

cd /absolute/path/to/my-project
hermes

Ici, /absolute/path/to/my-project est un espace réservé pour le chemin complet de votre projet. Sur l’écran de démarrage de Hermes, vérifiez le répertoire de travail et l’environnement dans lequel s’exécutent les commandes du terminal. Cette méthode de démarrage est prévue pour l’environnement de terminal local de Hermes sur le serveur. Si SSH ou Docker est configuré, l’agent peut exécuter les commandes dans un autre environnement ; vérifiez d’abord que le chemin du projet y est accessible.

Demandez à l’agent de confirmer son répertoire de travail réel à l’aide de son outil de terminal, puis lisez le README et les instructions du projet. Le nom d’un dossier mentionné dans un message ne suffit pas à le vérifier.

L’ordre ci-dessous est indiqué dans une version figée de la documentation et peut différer de celui de votre version installée de Hermes. Vérifiez les instructions à jour dans votre session. Hermes prend en charge AGENTS.md, mais sa lecture dépend de la priorité des fichiers de contexte. Selon la documentation officielle de Hermes, un seul type de fichier d’instructions est sélectionné, dans cet ordre : .hermes.md, puis AGENTS.override.md, AGENTS.md, CLAUDE.md et .cursorrules. Avant de commencer à travailler, vérifiez la présence d’un ancien .hermes.md ou d’un fichier personnel AGENTS.override.md : ne supposez pas que l’agent appliquera forcément le fichier AGENTS.md qui se trouve à côté.

Dans les instructions sélectionnées, conservez l’objectif du projet, les commandes de vérification et les restrictions concernant les modifications. N’en faites pas une archive de conversations. Si vous devez aussi transférer les paramètres des agents, il s’agit d’un autre processus ; son périmètre est expliqué dans le guide de migration de Claude Code vers Codex.

Confier une tâche à l’agent et vérifier le résultat#

Commencez par lui demander de prendre connaissance du projet sans apporter de modifications. Par exemple :

Nous travaillons sur un projet existant dans le dossier que j’ai indiqué.
Confirme le répertoire de travail réel à l’aide de l’outil de terminal.
Lis le README et les instructions actuelles du projet.
N’ouvre pas de fichiers contenant des secrets et n’affiche aucune valeur d’environnement.
Liste les commandes de vérification et les prérequis pour les exécuter.
Pour l’instant, ne modifie ni n’installe quoi que ce soit et ne pousse rien dans le dépôt.

Mettez-vous ensuite d’accord sur une petite tâche, comme corriger un texte dans l’interface. Précisez les fichiers ou la zone à modifier et interdisez les mises à jour accessoires des dépendances. Si vous souhaitez isoler l’expérience de la copie principale, renseignez-vous d’abord sur une copie de travail Git distincte avec worktree.

Évaluez le résultat à partir des modifications de fichiers et des vérifications du projet relancées. Avant une expérience susceptible d’échouer, sauvegardez la copie source et créez un point de restauration ; ne demandez pas à l’agent d’annuler toutes les modifications en bloc. Si une vérification échoue, comparez l’erreur à celle de la copie source : cela permet de distinguer un problème de transfert d’un défaut déjà présent.

Le transfert peut être considéré comme terminé lorsque la version requise des fichiers source est en place, que l’environnement a été restauré, que les données nécessaires sont disponibles dans un environnement de test sûr, que les vérifications réussissent et que Hermes travaille dans ce dossier précis. La publication de l’application pour les visiteurs est une étape distincte qui ne fait pas partie de cette vérification.

Découvrez Ailoot.