Claude Code, ChatGPT Codex: guide de démarrage

Les assistants de développement comme Claude Code et ChatGPT Codex changent déjà la manière de créer des outils internes, des prototypes et des applications métier.

Leur intérêt n’est pas de remplacer toute compétence technique. Leur intérêt est plus concret: accélérer la création, aider à structurer un projet, produire une première base exploitable, documenter le code, proposer des corrections et automatiser une partie du travail répétitif.

Pour une PME, un éditeur SaaS, une équipe métier ou une direction qui veut valider une idée rapidement, c’est un vrai levier. Un POC qui aurait demandé plusieurs jours peut parfois être posé en quelques heures. Une interface d’administration, un connecteur, un simulateur, un outil de reporting ou une API interne peuvent devenir beaucoup plus accessibles.

Mais pour que l’expérience reste saine, il faut démarrer avec un cadre propre: un dépôt Git, un environnement de développement reproductible, des consignes écrites, une attention particulière aux données envoyées aux modèles, et une vraie discipline de revue.

Ce guide donne une base de départ pragmatique.

Avant de commencer: les limites à garder en tête

Les outils de code assisté par IA sont puissants, mais ils ne transforment pas un projet logiciel en simple conversation magique.

Il faut garder plusieurs points en tête.

Un minimum de maîtrise du code reste nécessaire

Claude Code ou ChatGPT Codex peuvent lire un projet, proposer des modifications, créer des fichiers, corriger des erreurs et lancer des commandes. Mais ils peuvent aussi mal interpréter une intention, survoler un détail métier, ou produire du code qui fonctionne dans un cas simple mais casse dans un cas réel.

Il faut donc être capable de:

• relire les changements proposés;
• comprendre la structure générale du projet;
• lancer les tests;
• identifier un comportement étrange;
• refuser une modification qui semble trop large;
• demander une autre approche quand le modèle part dans la mauvaise direction.

Pour un POC, ce niveau peut rester raisonnable. Pour une mise en production, il devient beaucoup plus sérieux.

La compétence sysadmin est un vrai plus

Beaucoup de projets ne bloquent pas sur le code applicatif, mais sur l’environnement:

• base de données mal configurée;
• ports déjà utilisés;
• variables d’environnement absentes;
• permissions de fichiers incohérentes;
• conteneurs Docker qui ne démarrent pas;
• migration de base de données non appliquée;
• service mail ou stockage objet non simulé en local.

Une personne à l’aise avec Linux, Docker, les logs et les commandes de base ira beaucoup plus vite. C’est aussi pour cela que nous recommandons de travailler dans un environnement proche d’une exploitation réelle, même pour un prototype.

Le modèle peut produire des erreurs ou des failles

Un assistant peut écrire du code propre. Il peut aussi produire:

• une faille d’authentification;
• une mauvaise gestion des permissions;
• une injection SQL ou une validation insuffisante;
• une dépendance inutile;
• un contournement fragile;
• un code difficile à maintenir;
• un déploiement qui fonctionne localement mais pas en production.

La bonne pratique consiste à considérer l’IA comme un assistant de production, pas comme une autorité finale. Elle propose. Vous validez.

Les données envoyées aux modèles sont un sujet de gouvernance

Un assistant de code travaille avec du contexte: fichiers ouverts, extraits de code, prompts, erreurs, parfois captures d’écran ou logs.

Avant de lui donner accès à un projet, il faut se poser des questions simples:

• le code contient-il des secrets, tokens, clés API ou mots de passe;
• le dépôt contient-il des données clients;
• les logs contiennent-ils des emails, informations personnelles ou données métier sensibles;
• le fournisseur peut-il utiliser les échanges pour améliorer ses modèles selon le type de compte;
• le cadre contractuel est-il compatible avec vos exigences de souveraineté, confidentialité et conformité.

Ce point n’interdit pas l’usage de ces outils. Il oblige à les utiliser proprement. Sur des périmètres sensibles, il faut privilégier les offres avec garanties adaptées, désactiver l’entraînement quand l’option existe, éviter d’envoyer des secrets, et cadrer les usages dans une politique interne.

Pourquoi ces outils restent très utiles

Malgré ces limites, l’intérêt est réel.

Bien utilisés, Claude Code et ChatGPT Codex permettent de:

• créer rapidement un POC;
• explorer plusieurs architectures possibles;
• produire une première interface;
• ajouter des tests;
• documenter un projet existant;
• comprendre une base de code inconnue;
• automatiser des tâches répétitives;
• faire relire une modification avant merge.

Le bon angle n’est donc pas “l’IA va tout faire”. Le bon angle est plutôt: comment l’utiliser pour aller plus vite, sans perdre le contrôle technique.

VSCode: le poste de pilotage du projet

Visual Studio Code reste un très bon point d’entrée pour travailler avec ces assistants.

Son rôle n’est pas seulement d’afficher des fichiers. Il devient le point central où se rencontrent:

• le dépôt Git;
• le terminal;
• les extensions;
• les fichiers ouverts;
• les erreurs TypeScript ou lint;
• les conteneurs Docker;
• l’assistant IA;
• les instructions projet.

Avec une extension comme Claude Code ou Codex, l’assistant peut mieux comprendre le contexte: fichiers sélectionnés, structure du projet, erreurs visibles, commandes déjà lancées. Cela donne des réponses plus pertinentes qu’une conversation isolée où l’on copie-colle quelques extraits.

Documentation utile:

• Claude Code
• Codex par OpenAI

Les outils à installer

Avant de demander à l’assistant de générer une application, il faut poser un environnement correct.

Sous Windows: installer WSL

Sous Windows, nous recommandons de travailler avec WSL, le Windows Subsystem for Linux.

L’objectif est simple: développer dans un environnement Linux, plus proche de la majorité des serveurs de production, tout en gardant VSCode côté Windows.

WSL évite beaucoup de frictions:

• différences de chemins entre Windows et Linux;
• permissions de fichiers incohérentes;
• lenteurs sur certains accès disque;
• scripts shell qui se comportent différemment;
• dépendances pensées pour Linux.

Le réflexe à adopter: stocker le projet dans le système de fichiers Linux de WSL, par exemple dans ~/projects/mon-projet, et non dans un chemin Windows du type /mnt/c/Users/....

Installer Docker Desktop

Docker Desktop permet de lancer localement des services isolés: base de données, serveur mail de test, Redis, worker, application web, reverse proxy, etc.

Dans une logique de projet sérieux, Docker évite le fameux “ça marche sur mon poste”. L’environnement de développement devient décrit dans des fichiers, versionné dans Git, et beaucoup plus simple à relancer.

Sous Windows, Docker Desktop s’intègre avec WSL. La documentation officielle Docker recommande d’activer l’intégration WSL et de travailler depuis la distribution Linux pour une meilleure expérience.

Documentation utile:

• Docker Desktop avec WSL 2
• Développer avec Docker Desktop et WSL 2

Installer Git

Git est indispensable.

Même pour un prototype, il faut versionner le code. Cela permet de:

• revenir en arrière;
• comparer les modifications proposées par l’assistant;
• créer des branches;
• travailler avec des merge requests;
• auditer l’historique;
• déployer plus proprement.

Pour l’hébergement du dépôt, nous privilégions généralement GitLab ou Gitea dans une logique open source, maîtrisable et cohérente avec une approche souveraine. GitHub reste évidemment très répandu et peut être pertinent selon l’écosystème, mais ce n’est pas toujours le meilleur choix si l’objectif prioritaire est la maîtrise complète de la chaîne.

Les étapes pour démarrer un projet

Une fois les outils installés, l’objectif est de créer un cadre que l’assistant pourra comprendre.

1. Créer un dépôt Git

Commencez par créer un dépôt sur GitLab, Gitea ou votre forge habituelle.

Même si le projet est vide, ce dépôt sert de point d’ancrage:

• les changements sont suivis;
• les branches sont isolées;
• les retours arrière sont possibles;
• les futures mises en production seront plus simples.

Si vous partez d’un existant, importez-le dans ce dépôt avant de faire intervenir l’assistant.

2. Importer le projet dans WSL

Depuis votre terminal WSL, placez-vous dans un répertoire natif Linux:

mkdir -p ~/projects
cd ~/projects
git clone git@gitlab.example.com:organisation/mon-projet.git
cd mon-projet

Évitez de travailler directement dans /mnt/c/Users/....

Ce choix paraît secondaire, mais il évite beaucoup de problèmes: latences d’ouverture, différences de permissions, watchers de fichiers instables, conflits entre outils Windows et Linux.

Une fois dans le répertoire du projet, lancez VSCode:

code .

VSCode s’ouvrira alors connecté à l’environnement WSL. Le terminal intégré, les extensions et les commandes s’exécuteront dans le bon contexte.

3. Vérifier les extensions et Docker

Dans VSCode, vérifiez au minimum:

• l’extension WSL;
• l’extension Docker si vous voulez piloter les conteneurs depuis l’interface;
• l’extension Claude Code ou Codex selon l’outil choisi;
• le terminal ouvert dans WSL;
• Docker Desktop démarré;
• l’intégration Docker activée pour votre distribution WSL.

Dans le terminal:

git status
docker version
docker compose version

Ces commandes doivent répondre proprement avant de confier de grandes étapes à l’assistant.

4. Initier le projet avec Claude Code ou Codex

Une fois l’extension installée, connectez-vous au service correspondant.

Ensuite, commencez modestement. Une bonne première demande n’est pas “crée-moi tout le SaaS”. C’est plutôt:

Analyse ce dépôt. Explique-moi sa structure, les technologies utilisées, les commandes de développement, les risques visibles et les fichiers d'instructions que tu recommandes d'ajouter.

Sur un projet neuf, vous pouvez demander:

Nous allons créer un POC d'application web. Avant d'écrire du code, propose une architecture simple, dockerisée, avec une base de données, un environnement de développement reproductible et une stratégie de déploiement réaliste.

L’objectif est de faire réfléchir l’assistant avant de le laisser écrire.

5. Ajouter des instructions projet en Markdown

Les assistants de code deviennent beaucoup plus utiles quand ils disposent d’instructions écrites dans le dépôt.

Selon les outils, le nom exact du fichier peut varier, mais le principe reste le même: un ou plusieurs fichiers .md décrivent les règles du projet.

On peut y documenter:

• le contexte métier;
• le ton de l’application;
• les choix techniques;
• les commandes à utiliser;
• les règles de sécurité;
• les conventions de code;
• la stratégie Docker;
• la procédure de test;
• la méthode de déploiement;
• les choses à ne pas faire.

Dans un projet sérieux, ces fichiers sont aussi importants que le code. Ils réduisent les approximations du modèle.

Exemple d’instructions utiles

Un bon fichier d’instructions peut contenir ce type de règles:

# Instructions projet

## Objectif

Ce projet est un POC destiné à valider rapidement un usage métier. Le code doit rester simple, lisible et facile à reprendre.

## Environnement

- Utiliser Docker Compose pour le développement local.
- Prévoir une configuration proche de la production.
- Ne pas dépendre d'un service installé manuellement sur le poste développeur.
- Documenter chaque commande importante dans le README.

## Base de données

- Utiliser Prisma pour le schéma, les migrations et l'accès aux données.
- Ne jamais modifier manuellement la base sans migration documentée.
- Fournir des données de seed réalistes mais non confidentielles.

## Authentification

- Privilégier une authentification par magic link pour les premiers POC.
- Ne jamais stocker de mot de passe en clair.
- Prévoir une séparation claire entre utilisateurs, sessions et droits.

## Emails en développement

- Utiliser MailHog ou un équivalent local pour intercepter les emails.
- Ne jamais envoyer d'emails réels depuis l'environnement de développement.

## Sécurité

- Ne jamais écrire de secrets dans le dépôt.
- Valider les entrées côté serveur.
- Ajouter des contrôles d'autorisation sur les routes sensibles.
- Signaler explicitement les hypothèses de sécurité non traitées.

## Déploiement

- Prévoir une image Docker de production.
- Décrire les variables d'environnement nécessaires.
- Documenter les migrations à exécuter avant ou pendant le déploiement.
- Prévoir une procédure de rollback simple.

Ce type de document donne au modèle une boussole. Il comprend mieux ce que vous attendez, ce qu’il doit éviter, et comment rester cohérent d’une session à l’autre.

Pourquoi privilégier Docker en développement et en production

Docker n’est pas obligatoire pour tous les projets, mais c’est souvent le meilleur compromis pour un POC qui peut devenir sérieux.

En développement, Docker Compose permet de lancer:

• l’application;
• la base de données;
• MailHog pour les emails;
• Redis ou un autre service de file;
• un worker;
• éventuellement un reverse proxy local.

En production, une image Docker bien construite facilite:

• les déploiements reproductibles;
• les mises à jour;
• les rollbacks;
• la séparation entre code, configuration et données;
• l’exploitation sur une infrastructure Linux standard.

Ce fonctionnement correspond bien à une approche d’infogérance moderne: versionner, automatiser, superviser, documenter.

Pourquoi utiliser MailHog en développement

Dès qu’un projet envoie des emails, le risque est simple: envoyer par erreur un vrai message à un vrai utilisateur depuis un environnement de test.

MailHog évite cela. Il se comporte comme un serveur SMTP local qui capture les emails et les affiche dans une interface web. Vous pouvez donc tester:

• les magic links;
• les invitations;
• les notifications;
• les relances;
• les modèles d’emails.

Sans toucher à de vraies boîtes mail.

Pour les POC, c’est très pratique. Pour les projets plus avancés, c’est aussi une bonne habitude de sécurité.

Pourquoi Prisma peut être un bon choix

Sur un projet web moderne, Prisma peut aider à garder une base de données lisible:

• le schéma est versionné;
• les migrations sont explicites;
• les types côté applicatif sont générés;
• les accès aux données sont plus structurés;
• les seeds facilitent les environnements de test.

Cela ne dispense pas de comprendre SQL ni la modélisation. Mais pour un POC ou une application métier classique, Prisma donne un cadre clair que les assistants IA comprennent plutôt bien.

Conseils de travail avec l’assistant

La qualité des réponses dépend énormément du contexte.

Un prompt vague produit souvent une solution moyenne. Un prompt précis, avec contraintes, objectifs et critères de validation, produit beaucoup moins d’approximations.

Avant une grosse tâche, donnez toujours:

• l’objectif métier;
• les fichiers concernés;
• les contraintes techniques;
• ce qui doit rester inchangé;
• les critères de succès;
• les commandes de test attendues.

Exemple:

Ajoute une authentification par magic link. Utilise Prisma pour les tables nécessaires, MailHog en développement, et garde une séparation claire entre demande de lien, validation du token et création de session. Avant de coder, propose un plan et liste les risques de sécurité à traiter.

Utiliser le mode plan pour les grosses étapes

Quand la demande est large, demandez d’abord un plan.

C’est utile pour:

• découper le travail;
• comparer plusieurs choix techniques;
• repérer les risques;
• valider l’ordre des étapes;
• éviter que l’assistant modifie trop de fichiers d’un coup.

Le mode plan est particulièrement utile pour:

• mettre en place une authentification;
• ajouter un système de paiement;
• migrer une base de données;
• refondre une architecture;
• préparer un déploiement;
• corriger un bug complexe.

La bonne pratique consiste à demander le plan, le relire, corriger les choix si nécessaire, puis seulement lancer l’implémentation.

Faire auditer le code par l’assistant

Une fois une fonctionnalité produite, ne vous arrêtez pas au premier résultat.

Demandez un audit:

Relis les changements comme une revue de code. Priorise les bugs, les failles de sécurité, les erreurs de logique, les oublis de tests et les risques de régression. Donne-moi les points bloquants avant les suggestions de confort.

Vous pouvez aussi croiser les modèles: faire produire une fonctionnalité par un assistant, puis la faire relire par un autre. Ce n’est pas une garantie absolue, mais cela permet souvent de détecter des angles morts.

Faire auditer avant une mise en production

Pour un POC interne sans données sensibles, une validation raisonnable peut suffire.

Pour une application exposée sur Internet, utilisée par des clients, connectée à une base réelle ou manipulant des données confidentielles, le niveau d’exigence change.

Dans ce cas, si vous n’avez pas les compétences internes, il est préférable de faire auditer:

• le code;
• l’authentification;
• les permissions;
• les dépendances;
• la configuration Docker;
• les variables d’environnement;
• les sauvegardes;
• la stratégie de déploiement;
• l’exposition réseau;
• les journaux et la supervision.

Un assistant peut aider à préparer cet audit. Il ne remplace pas un regard expert sur un périmètre de production.

On vous aide à déployer

Créer un POC avec Claude Code ou ChatGPT Codex est une première étape. Le faire passer en production demande un autre niveau de maîtrise: sécurité, architecture, Docker, variables d’environnement, migrations, sauvegardes, supervision, exposition réseau et procédure de rollback.

Chez Forget About IT, nous pouvons vous accompagner pour transformer un prototype en service exploitable, sécurisé, maîtrisé de bout en bout et adapté à votre projet. L’objectif n’est pas de sur-complexifier: c’est de poser le bon cadre technique, au bon niveau, pour que votre application puisse vivre sereinement.

Prendre rendez-vous

FAQ: Claude Code, ChatGPT Codex et démarrage projet

Claude Code et ChatGPT Codex permettent-ils de créer une application sans savoir coder ?

Ils peuvent accélérer fortement un prototype, mais un minimum de compréhension du code reste nécessaire pour relire, tester, corriger et sécuriser ce qui est produit.

Pourquoi utiliser WSL sous Windows pour un projet de développement ?

WSL permet de travailler dans un environnement Linux proche de la production, avec de meilleures performances sur les fichiers Linux et moins de problèmes de permissions qu’un projet stocké dans les répertoires Windows.

Docker est-il indispensable pour travailler avec un assistant de code ?

Il n’est pas toujours indispensable, mais il rend l’environnement reproductible. C’est très utile pour lancer une base de données, MailHog, des services de développement ou une version proche de la production.

Peut-on envoyer du code confidentiel à un modèle IA ?

Il faut le traiter comme un vrai sujet de gouvernance: vérifier les conditions du fournisseur, le type d’abonnement, les réglages de conservation des données et éviter d’exposer secrets, données clients ou informations sensibles.

Quel est le meilleur usage de ces outils pour une PME ?

Le meilleur point d’entrée est souvent le POC: cadrer une idée, générer une première version, documenter, tester et faire auditer avant toute mise en production.

Le bon usage: accélérer sans abandonner le contrôle

Claude Code et ChatGPT Codex sont de très bons accélérateurs.

Ils permettent de passer plus vite de l’idée au prototype, de documenter un projet, d’explorer des choix techniques, de corriger des erreurs, et de rendre le développement plus accessible à des équipes qui n’auraient pas lancé le chantier autrement.

Mais le résultat dépend du cadre:

• un dépôt Git propre;
• un environnement WSL/Docker stable;
• des consignes projet en Markdown;
• des secrets absents du dépôt;
• des tests;
• des revues;
• une attention réelle à la sécurité;
• une mise en production accompagnée quand l’enjeu le justifie.

L’IA est très utile pour créer, assister et accélérer. Le rôle de l’équipe reste de cadrer, vérifier et exploiter proprement.

Chez Forget About IT, c’est exactement la logique que nous défendons sur l’infrastructure comme sur le développement: automatiser ce qui peut l’être, documenter les décisions, garder la maîtrise, et ne pas confondre vitesse de création avec robustesse de production.