Comment écrire un logiciel avec Claude Code ou Codex en 2026

En 2026, écrire un logiciel avec Claude Code ou Codex ne consiste plus à demander une fonction, copier le code et espérer qu'il marche. Ces outils sont des agents de programmation : ils peuvent explorer un projet, modifier plusieurs fichiers, exécuter des commandes, lancer des tests et corriger leur propre travail.

Ils permettent à une personne motivée de construire beaucoup plus qu'avant. Mais ils ne transforment pas automatiquement une idée vague en produit sécuritaire, rentable et maintenable. La qualité dépend encore de la définition du problème, des contraintes données à l'agent et de la vérification du résultat.

Voici une méthode réaliste pour partir un logiciel avec l'un ou l'autre.

Claude Code ou Codex : lequel choisir ?

Les deux peuvent travailler directement dans un dépôt de code et utiliser les outils installés sur votre ordinateur. Le meilleur choix est souvent celui qui s'intègre le mieux à votre environnement et que vous êtes prêt à apprendre.

Claude Code est principalement utilisé dans le terminal. Il lit les instructions persistantes d'un projet, peut lancer des commandes et s'intègre à des outils externes. Anthropic recommande notamment un fichier CLAUDE.md concis pour expliquer les commandes, l'architecture, les tests et les conventions du dépôt.

Codex est offert dans plusieurs surfaces, dont le terminal, l'éditeur et l'application ChatGPT. Il peut lire et modifier les fichiers du dossier choisi, travailler dans un environnement contrôlé et suivre les consignes d'un fichier AGENTS.md. La documentation officielle recommande de préciser le but, le contexte, les contraintes et les critères qui définissent un travail terminé.

Ne choisissez pas uniquement à partir d'un classement publié cette semaine. Sur un vrai projet, la capacité à comprendre votre code, à utiliser vos outils et à vérifier le résultat compte davantage qu'un test isolé.

Étape 1 : réduire l'idée à un premier parcours

« Fais-moi un ERP » est une mauvaise première demande. Un ERP comprend des dizaines de rôles, de règles et d'exceptions. L'agent comblera les trous avec des suppositions et produira une démonstration convaincante, mais incohérente.

Commencez plutôt par un parcours vertical :

Un représentant crée un client, prépare une soumission avec trois produits, applique une marge autorisée, puis génère un PDF que le gestionnaire peut approuver. Les données doivent être sauvegardées et chaque modification de prix doit être journalisée.

Ce parcours touche l'interface, les données, les règles et un résultat utilisable. Il est assez petit pour être vérifié.

Étape 2 : préparer le projet avant de demander du code

Même un petit logiciel devrait commencer avec quelques décisions écrites :

• le problème et les utilisateurs visés;
• ce que la première version doit accomplir;
• ce qu'elle ne doit pas faire;
• les données sensibles qu'elle contiendra;
• les rôles et permissions;
• les technologies déjà choisies, s'il y en a;
• les commandes pour lancer, tester et bâtir le projet;
• la définition de « terminé ».

Placez les règles durables dans CLAUDE.md ou AGENTS.md, selon l'outil. N'y mettez pas le roman complet du produit. Gardez des instructions courtes, vérifiables et réellement utiles à chaque tâche.

Étape 3 : demander un plan avant l'implémentation

Pour une fonction importante, utilisez une séquence simple : explorer, planifier, coder, tester, réviser.

Un bon premier message ressemble à ceci :

Lis le projet et les instructions existantes. Je veux ajouter le parcours de soumission décrit dans docs/soumissions.md. Avant de modifier le code, identifie les fichiers concernés, les décisions manquantes, les risques de sécurité et les tests nécessaires. Propose ensuite un plan par petites tranches. Ne commence pas l'implémentation avant d'avoir terminé l'analyse.

Ce prompt donne un résultat, une source, des limites et une étape de vérification. Il évite aussi que l'agent invente une nouvelle architecture sans avoir regardé celle qui existe.

Étape 4 : construire par petites tranches vérifiables

Demandez une fonction complète à la fois. Après chaque tranche :

1. lancez les tests et la vérification de types;
2. ouvrez réellement l'application;
3. essayez le parcours normal et deux cas d'erreur;
4. regardez les changements dans Git;
5. faites corriger ce qui ne respecte pas le projet;
6. enregistrez une version fonctionnelle avant de continuer.

Un agent peut produire beaucoup de code rapidement. C'est précisément pourquoi les petites étapes sont importantes : une mauvaise décision d'architecture peut autrement se répandre dans cinquante fichiers avant d'être remarquée.

Étape 5 : lui donner les moyens de voir ses erreurs

Un agent sans tests doit deviner s'il a réussi. Donnez-lui des preuves : messages d'erreur, captures d'écran, tests automatisés, règles de validation et données représentatives.

Pour une fonction calculant un prix, fournissez des exemples d'entrée et de sortie. Pour une interface, demandez une vérification sur mobile et sur ordinateur. Pour une migration, exigez une comparaison du nombre d'enregistrements et des totaux avant et après.

Le cycle devient alors : modifier, exécuter, observer, corriger. C'est beaucoup plus fiable qu'une longue génération suivie d'une révision à l'œil.

Ce que l'agent ne décide pas à votre place

Claude Code et Codex peuvent proposer des solutions, mais certaines décisions vous appartiennent :

• Qui a le droit de voir ou modifier chaque donnée ?
• Quelle erreur pourrait coûter de l'argent ou blesser quelqu'un ?
• Quelle information doit être conservée pour une obligation légale ?
• Que se passe-t-il si un service externe tombe en panne ?
• Comment récupérerez-vous les données et le code ?
• Qui maintiendra le logiciel dans deux ans ?

Une application peut fonctionner en démonstration tout en ayant des accès trop larges, aucune sauvegarde, des secrets dans le code ou des calculs non testés.

Les erreurs les plus fréquentes du vibe coding

Ajouter des fonctions avant de stabiliser les fondations. L'authentification et le modèle de données deviennent difficiles à corriger après vingt écrans.

Accepter chaque commande proposée. Une dépendance peut être inutile, abandonnée ou incompatible. Demandez pourquoi elle est nécessaire.

Donner tous les accès. Gardez les permissions limitées au projet et confirmez les actions sensibles. Un agent qui peut exécuter des commandes peut aussi propager une erreur très vite.

Ne jamais regarder le code ni le diff. Vous n'avez pas besoin de comprendre chaque ligne, mais vous devez savoir quels fichiers, services et données ont changé.

Déployer directement la première version. Utilisez un environnement d'essai, des comptes fictifs et des sauvegardes avant les vrais utilisateurs.

Jusqu'où peut-on aller sans développeur ?

Une personne non technique peut construire un prototype, valider un parcours et parfois exploiter un petit outil interne à faible risque. Plus le logiciel touche des paiements, des renseignements personnels, des permissions complexes, des opérations industrielles ou plusieurs intégrations, plus une révision expérimentée devient importante.

L'objectif n'est pas de vous enlever le clavier. C'est de protéger ce que vous avez construit. DevActif offre justement un service de revue de code et d'accompagnement pour les vibe codeurs : architecture, sécurité, performance, déploiement et plan de reprise. Vous continuez à développer vite; nous vous aidons à éviter que les raccourcis du prototype deviennent les problèmes de la production.