Faire tourner son IA sur un serveur distant, sans navigateur
Votre IA travaille très bien, tant que votre ordinateur est allumé. Dès que vous voulez la faire tourner sur un serveur distant, tout se complique : pas de navigateur pour la fenêtre de connexion, une session SSH austère, et une question à laquelle personne ne répond clairement : clé API ou OAuth ? Résultat, le projet d'une IA qui travaille la nuit reste au fond d'un tiroir.
Cette masterclass vous donne la méthode complète pour authentifier Claude Code sur un serveur sans navigateur : d'abord la décision (clé API pour une IA qui tourne seule, OAuth distant pour un usage ponctuel devant l'écran), puis la séquence qui fait que ça marche et que ça tient dans la durée.
Ce que cet exercice ne peut pas casser
L'exercice se fait sur une feuille : vous ne lancez aucune commande, vous ne touchez pas encore au serveur. Au pire, vous changez de porte avant d'avoir tapé quoi que ce soit. Et noter « je ne sais pas » sur une ligne est une vraie réponse, pas un échec.
Ce que vous saurez faire à la fin
- Choisir entre clé API et OAuth distant en une seule question : qui est devant l'écran ?
- Authentifier Claude Code sur un serveur en SSH, sans navigateur, de façon à ce que ça tienne entre les sessions.
- Ranger votre clé proprement : jamais dans un dépôt git, jamais en clair, toujours un rangement décidé d'avance.
- Niveau membre· le prompt prêt à coller qui diagnostique votre porte, déroule les commandes une par une avec leur résultat attendu, et passe en mode interview si vous hésitez.
- Niveau Pro· on se connecte ensemble à votre serveur et on déroule l'authentification en direct, jusqu'au test qui prouve que ça tient.
Une seule question tranche : qui travaille, vous ou l'IA seule ?
La décision d'abord, les commandes ensuite
Authentifier une IA sur un serveur n'est pas un problème de commandes, c'est un problème de décision. La question qui tranche : qui travaille ? Si c'est l'IA seule (crons, scripts qui tournent la nuit), la porte s'appelle clé API. Si c'est vous, ponctuellement, connecté en SSH, la porte s'appelle OAuth. Une fois la porte choisie, le reste est une séquence en cinq mouvements : préparer, authentifier, sécuriser, vérifier, anticiper.
1Choisir la porte : clé API ou OAuthdoute : « laquelle est faite pour mon cas ? »
Une seule question tranche : qui est devant l'écran ? Personne, parce que ce sont des crons et des tâches automatiques qui tournent la nuit : clé API. Vous, ponctuellement, en SSH : OAuth distant. Si votre usage est flou, ne forcez pas la décision : clarifiez l'usage d'abord, la porte en découle toujours.
2Préparer le serveurdoute : « et si rien n'est installé ? »
Avant toute authentification, le serveur doit avoir Node.js et Claude Code. On vérifie d'abord ce qui est déjà là, on installe seulement ce qui manque. La règle de confort : pour chaque commande, savoir en une ligne ce qu'elle fait et ce qu'on doit voir en retour. C'est ce qui sépare une installation maîtrisée d'un copier coller anxieux.
3Authentifier selon la porte choisiedoute : « sans navigateur, comment ça peut marcher ? »
Pour la clé API : vous la créez, vous l'exportez sur le serveur, vous la rendez persistante entre les sessions, puis vous testez. Pour l'OAuth : il n'y a pas de navigateur sur le serveur, donc la séquence passe par le vôtre. Vous copiez l'URL fournie dans le navigateur de votre machine locale, vous validez, et vous ramenez le résultat dans la session SSH.
4Sécuriser la clédoute : « où la ranger sans me faire avoir ? »
La règle est absolue : jamais dans un dépôt git, jamais en clair. Deux rangements concrets : un gestionnaire de secrets, ou un fichier .env protégé. Et dans vos notes et vos exemples, toujours un placeholder explicite comme sk-ant-votre-cle-ici, jamais la vraie clé.
5Vérifier que ça tientdoute : « comment savoir que ça remarchera demain ? »
Une authentification qui marche une fois ne suffit pas : elle doit tenir entre les sessions. Une à trois commandes de test prouvent que tout fonctionne et fonctionnera encore demain. Si l'une échoue, c'est une information, pas une catastrophe : chaque échec a sa marche à suivre.
6Anticiper les pannesdoute : « et quand ça casse à trois heures du matin ? »
Pour chaque porte, trois erreurs reviennent tout le temps. Les connaître avant qu'elles arrivent, avec la correction de chacune en une ligne, c'est la différence entre une IA qui tourne pendant que vous dormez et une nuit de débogage.
À vous de jouer : votre fiche de situation serveur
Prenez une feuille ou une note. Cinq lignes suffisent, mais chacune doit être tranchée.
Le résultat, en 30 secondes
À partir de votre fiche de situation, le prompt joue l'ingénieur système : il recommande votre porte, puis donne chaque commande, une par bloc, avec en dessous ce qu'elle fait et ce que vous devez voir en retour.
Votre porte : clé API, parce que vos crons tournent la nuit sans personne devant l'écran. Puis : préparer le serveur (vérifier Node.js et Claude Code), authentifier, sécuriser la clé avec un rangement concret, vérifier avec des commandes de test et leur sortie attendue. En bas : les trois erreurs les plus probables pour votre porte, et la correction de chacune en une ligne.
Le prompt prêt à coller
# RÔLE Tu es un ingénieur système qui authentifie Claude Code sur des serveurs Linux depuis des années. Tu es rigoureux et pédagogue : tu expliques chaque commande avant de la donner. Tu ne t'appuies QUE sur ce que je te donne. Ce qui te manque (mon système, mon usage, mon abonnement), tu me le demandes, tu n'inventes rien. Une commande dont tu n'es pas sûr qu'elle marche sur ma configuration, tu me le dis au lieu de l'affirmer. # CONTEXTE Je veux faire tourner Claude Code sur mon serveur distant, sans navigateur. Je me connecte en SSH. Je dois choisir entre une clé API (pour une IA qui tourne seule, crons et scripts) et l'authentification OAuth (pour un usage ponctuel devant l'écran), puis exécuter les commandes pour que ça marche et que ça tienne dans la durée. Ma situation (si je la connais) :
Le prompt déroule toute l'authentification à votre place : il diagnostique votre porte, prépare le serveur, donne chaque commande avec ce qu'elle fait et ce que vous devez voir en retour, sécurise la clé et liste les trois pannes les plus probables. Si vous hésitez encore, il passe en mode interview et vous pose les questions une par une. Laissez votre email, je vous l'envoie.
Vérifiez que c'est à vous
Vous voulez qu'un script analyse vos ventes chaque nuit à trois heures sur votre serveur, sans personne de connecté. Quelle porte choisissez-vous ?
D'abord avec vos mots, sans regarder les options :
Expliquez-le pour l'ancrer
Expliquez en une phrase, à quelqu'un qui n'a jamais touché un serveur : pourquoi la clé API pour les crons, et l'OAuth pour l'usage devant l'écran ? Si vous savez le dire simplement, la décision est à vous.
Ce que vous savez faire maintenant
- Trancher la porte d'authentification à partir de l'usage : IA autonome, clé API ; usage devant l'écran, OAuth distant.
- Dérouler la séquence complète : préparer le serveur, authentifier, sécuriser la clé, vérifier que ça tient.
- Anticiper les pannes les plus fréquentes au lieu de les découvrir au milieu de la nuit.
La porte se choisit selon l'usage : si l'IA travaille seule, clé API ; si vous êtes devant l'écran, OAuth.
Continuez seul
Votre fiche de situation est prête, la porte est choisie. Brique suivante :
Toutes les masterclass →Faites-le avec moi
On se connecte ensemble à votre serveur et on déroule l'authentification en direct, jusqu'au test qui prouve que ça tient. Vous repartez avec une IA qui tourne pendant que vous dormez.