Opus 5 contre GPT-5.6 : le test de développement d'une application métier

Le verdict des lignes de code et de l'architecture

L'analyse brute des dépôts générés met en lumière une fracture nette entre les deux approches. À l'issue du test, un script de comparaison exécuté dans une sandbox révèle des écarts massifs dans la production de code. Claude Code, propulsé par Opus 5, a généré un écosystème complet de 106 fichiers. Son arborescence descend jusqu'à cinq niveaux de profondeur, structurant proprement les éléments statiques, les démonstrations et les logiques métiers. Il livre plus de 15 000 lignes de code, intègre huit fichiers de tests spécifiques et déclare six dépendances claires. Ce volume impressionnant se traduit par un poids total de 692 kilo-octets. Le système a même pris le temps de documenter ses décisions architecturales à travers six fichiers distincts, assurant une maintenabilité exemplaire pour les futures itérations.

De son côté, Codex sous GPT-5.6 livre une structure beaucoup plus légère et directe. Son dépôt final compte seulement 22 fichiers pour un peu plus de 4 000 lignes de code. Le poids total plafonne à 148 kilo-octets avec une profondeur maximale de deux dossiers. Fait marquant, Codex ne déclare aucune dépendance et se contente de deux fichiers de test basiques. Cette frugalité technique s'accompagne pourtant d'une interface utilisateur nettement plus aboutie dès le premier jet. L'application générée par Codex propose un menu latéral ergonomique et un agencement épuré, là où Claude Code se perd dans une navigation par en-tête confuse et des proportions visuelles hasardeuses.

Ces chiffres illustrent deux philosophies de développement fondamentalement différentes. Le premier construit une forteresse technique prête à encaisser des règles métiers complexes et à évoluer dans le temps. Le second monte un décor visuel très fonctionnel et extrêmement rapide à déployer, idéal pour une démonstration immédiate.

Le piège du biais visuel dans l'évaluation d'un projet

Face à deux applications fraîchement générées, l'œil humain se dirige naturellement vers l'interface. C'est ici que frappe le biais du débutant. En ouvrant la version de Codex, la clarté du tableau de bord et la fluidité de la navigation donnent une illusion d'achèvement. Tout semble prêt à l'emploi. Pourtant, évaluer un logiciel métier sur son apparence constitue une erreur stratégique majeure. Une interface élégante cache souvent une logique superficielle qui s'effondrera à la première sollicitation complexe.

Dans le cas d'une application juridique, les véritables enjeux se situent sous la surface. Le calcul des délais procéduraux, la gestion des conflits d'intérêts ou le respect des invariants de la CARPA exigent une rigueur absolue. Si tu te laisses séduire par le design de Codex sans auditer son backend, tu risques de déployer un outil incapable de soutenir la réalité du métier. L'absence de tests poussés, le manque de documentation et la faible profondeur de l'arborescence sont des signaux d'alerte clairs pour un passage en production.

Un développeur expérimenté regarde d'abord les fonctionnalités brutes. Il vérifie si les relations entre les bases de données tiennent la charge. Il s'assure que chaque clic déclenche la bonne action dans le moteur Python et que les données de test s'intègrent sans erreur. Le design et l'agencement des éléments restent secondaires lors d'un premier jet. Ils se corrigent facilement dans un second temps. Privilégier l'esthétique au détriment de l'architecture technique te condamne à accumuler une dette technique impossible à résorber par la suite.

La gestion de l'exécution et des agents autonomes

La différence de comportement entre les deux modèles se manifeste dès les premières secondes suivant l'envoi du prompt. Claude Code adopte une posture d'ingénieur logiciel méthodique. Il analyse le cahier des charges et pose immédiatement des questions de cadrage. Il propose d'utiliser FastAPI, Jinja et htmx, puis demande quel périmètre exact il doit couvrir pour cette première phase. Cette étape de validation garantit un alignement parfait avec tes attentes avant d'écrire la moindre ligne de code.

À l'inverse, Codex agit comme un bulldozer d'exécution. Il lui faut environ deux minutes pour constater que le dossier cible est vide, puis il fonce tête baissée. Il génère son propre plan d'action et commence à coder sans poser la moindre question d'amorçage. S'il rencontre un obstacle, il s'acharne dessus jusqu'à le franchir, quitte à boucler inutilement sur une tâche bornée. Cette exécution aveugle explique sa rapidité fulgurante, mais limite sa capacité à anticiper les problèmes structurels globaux.

L'expérience utilisateur dans le terminal diffère également de manière radicale. Lorsque tu actives le travail en multi-agent pour paralléliser les tâches sans collision, Claude Code affiche clairement ses sous-agents. Tu peux cliquer sur une tâche en cours, comme la création du schéma SQL ou le calcul des jours fériés, pour inspecter le travail en temps réel et rediriger l'IA si nécessaire. Codex propose une interface beaucoup plus hermétique. Les actions parallèles s'exécutent dans une boîte noire visuelle, rendant le suivi du projet particulièrement opaque pour le pilote.

Le test en conditions réelles sur un cahier des charges juridique

Pour obtenir une comparaison fiable, l'environnement de test doit être strictement identique. Les deux assistants tournent sur une configuration agnostique. Ils partagent les mêmes compétences intégrées et les mêmes points d'accroche. La seule variable reste leur propre moteur de raisonnement. Le défi consiste à créer Athena, une application de gestion pour un avocat individuel traitant entre 40 et 120 dossiers simultanément, avec l'objectif de centraliser des données clients habituellement éparpillées.

Le cahier des charges impose des contraintes techniques fortes. Le système doit intégrer un générateur de données de démonstration et permettre l'importation de pièces. Plus important encore, le moteur de calcul doit être impérativement codé en Python pour gérer des éléments critiques basés sur la loi française.

• Le respect strict des articles 640 à 644 du Code de procédure civile.
• L'intégration de la loi du 31 décembre 1971 sur la profession d'avocat.
• La conformité totale avec le décret CARPA pour la gestion des fonds.
• Le calcul précis des zones horaires, des jours fériés et des conflits d'intérêts.

La stratégie d'orchestration selon la phase du projet

Le chronomètre confirme les observations structurelles. Codex a bouclé l'application en quarante-deux minutes. Opus 5 a nécessité une heure et dix-neuf minutes pour arriver au bout de son processus. Cette différence de temps n'indique pas un vainqueur absolu, mais souligne deux cas d'usage distincts. Chercher à déterminer quel est le meilleur modèle de façon binaire n'a aucun sens technique face à la réalité du terrain.

La véritable compétence réside dans l'orchestration de ces outils. Si tu dois valider rapidement un concept auprès d'un client ou tester une ergonomie, Codex s'impose comme l'outil idéal. Sa capacité à générer une interface propre et fonctionnelle en un temps record te donne un avantage décisif pour le prototypage. En revanche, dès que tu entres dans la phase de production d'un logiciel métier, Claude Code devient indispensable. Sa lenteur relative est le prix à payer pour obtenir un code testé, documenté et architecturé pour durer.

Une approche hybride offre souvent les meilleurs résultats. Tu peux parfaitement utiliser Claude Code pour bâtir les fondations techniques, le schéma de base de données et les moteurs de calcul complexes. Une fois ce socle validé, tu confies le dépôt à Codex pour qu'il retravaille l'interface utilisateur et fluidifie la navigation. Comprendre les forces asymétriques de chaque modèle te permet de construire des systèmes rentables et solides.