Analyser un dépôt en profondeur

Leçon recadrée le 3 novembre 2026 d’après le manuel de Codex : « Deep Research for GitHub » n’est pas une fonction de Codex. L’analyse d’un dépôt se fait avec Codex en lecture seule, et la recherche approfondie (deep research) est une fonction de ChatGPT Work, disponible selon le compte et l’espace de travail. Le tableau de durées comparées de l’ancienne version, sans source, est retiré. Sources : Codex CLI · Non-interactive mode.

Analyser des repositories en profondeur

Avant de modifier un code, il faut souvent le comprendre : l’architecture d’un projet hérité, ses dépendances, sa dette technique. Deux outils s’y prêtent. Codex analyse un dépôt de l’intérieur — il lit les fichiers, l’historique Git, lance les commandes de diagnostic — et peut le faire sans rien modifier. La recherche approfondie (deep research) de ChatGPT Work mène, elle, une investigation sur plusieurs sources et rend un rapport sourcé : c’est l’outil des questions qui dépassent le dépôt, comme l’évaluation d’une bibliothèque externe.

Analyser sans rien modifier

Une tâche Codex ordinaire exécute une action : écrire du code, corriger un bug, générer des tests. Pour une analyse, demandez au contraire à Codex de synthétiser sans rien modifier, et donnez-lui les moyens de s’y tenir : passez la session en lecture seule (/permissions, mode read-only), ou lancez l’analyse avec codex exec, qui s’exécute par défaut dans un bac à sable en lecture seule. Il parcourt potentiellement des centaines de fichiers, examine l’historique Git, et rend un rapport détaillé. Cette différence se lit dès la formulation, qui porte sur une compréhension et non sur une modification :

"Analyse l'architecture de ce projet, sans modifier de fichier. 
Comment les données circulent de l'API jusqu'à la base 
de données ? Quels sont les patterns utilisés ? Où sont 
les points de fragilité ?"

Le résultat n’est pas un commit mais un document structuré, avec des références aux fichiers pertinents et des recommandations. Vous le relisez, vous le discutez en réunion technique, vous le corrigez là où il se trompe.

Accélérer l’onboarding technique

Un développeur qui rejoint une équipe passe généralement ses deux premières semaines à reconstituer mentalement une carte que personne n’a jamais écrite : quel service appelle quoi, pourquoi ce module porte un nom qui ne correspond plus à son contenu, où se cache la logique de facturation. Codex peut dessiner cette carte à sa place :

"Analyse ce repository et génère un guide d'onboarding 
pour un nouveau développeur. Couvre :
- L'architecture générale et les couches
- Les conventions de nommage et de structure
- Le flux d'une requête typique de bout en bout
- Les fichiers les plus importants à lire en premier
- Les pièges courants et les particularités du projet"

Le document obtenu sert de référence pendant les premières semaines et se corrige au fil des retours de l’équipe. Cet exercice de correction a une vertu inattendue : il fait apparaître les zones d’ombre que personne n’avait pris la peine de documenter, parce que « tout le monde sait comment ça marche ».

Auditer les dépendances et la dette technique

Le deuxième usage naturel relève de l’inventaire. Une base de code de trois ans accumule des bibliothèques abandonnées, des doublons fonctionnels et des imports morts que plus personne n’ose supprimer faute d’une vue d’ensemble :

"Analyse toutes les dépendances du projet (package.json 
et lock file). Identifie :
- Les packages obsolètes (dernière mise à jour > 1 an)
- Les vulnérabilités connues
- Les packages en double (même fonctionnalité)
- Les packages inutilisés (importés nulle part)
- Les packages avec des licences incompatibles"

L’analyse croise ici le package.json, le fichier de verrouillage et les imports réellement présents dans le code ; pour les vulnérabilités connues et l’état de maintenance des paquets, elle a besoin de données publiques, donc d’un accès réseau ou des outils d’audit de votre gestionnaire de paquets (npm audit, par exemple), à autoriser explicitement. L’évaluation de la dette technique obéit à la même logique, avec une exigence supplémentaire — la dernière ligne de la demande. Sans critère de tri, vous obtenez une liste de quarante problèmes dont personne ne sait par lequel commencer.

"Évalue la dette technique de ce projet. Analyse :
- La complexité cyclomatique des modules principaux
- Les fichiers les plus modifiés (hotspots Git)
- Les patterns de code dupliqué
- Les TODO et FIXME non résolus
- La couverture de tests par module
Classe les problèmes par impact et effort de correction."

L’intérêt de ces analyses tient au rapport entre le temps investi et le résultat : quelques consignes précises remplacent des jours de lecture. Mesurez-le sur vos propres projets plutôt que de vous fier à des ordres de grandeur génériques, et relisez toujours le rapport : il peut se tromper, notamment sur ce que le dépôt ne contient pas.

Évaluer un projet externe avant de l’adopter

Pour une bibliothèque open source que vous envisagez d’adopter, la question dépasse le dépôt : fréquence des versions, activité des issues, réputation. C’est le terrain de la recherche approfondie de ChatGPT Work — dans l’application de bureau, passez en Work, ouvrez les Plugins et choisissez Deep research ; sur le web, ouvrez le menu + d’une conversation Work —, selon ce que votre compte et votre espace de travail permettent :

"Analyse le repository github.com/org/library. 
Évalue sa maturité :
- Fréquence des releases et maintenance
- Qualité de la documentation
- Activité de la communauté (issues, PRs)
- Couverture de tests
- Recommandation : est-ce sûr de l'adopter en production ?"

C’est la vérification que l’on saute presque toujours, faute d’une demi-journée à y consacrer, et dont l’absence se paie deux ans plus tard : la bibliothèque n’est plus maintenue, son mainteneur unique a disparu, et vous héritez d’une dépendance à réécrire dans l’urgence.

Obtenir des rapports exploitables

La qualité du rapport dépend directement de la précision de la question. « Où sont les points de fragilité ? » produit un résultat autrement plus utile que « Analyse le projet », parce que la première formulation impose un angle et force une hiérarchie. Demandez également un format explicite — « classe par priorité », « organise par module » — pour obtenir un document que vous pourrez parcourir plutôt que lire de bout en bout. Enchaînez ensuite sur des tâches Codex concrètes qui corrigent les problèmes identifiés : l’analyse cesse alors d’être un rapport de plus pour devenir le point de départ d’un plan de travail. Partagez enfin ces rapports avec l’équipe, car leur valeur croît avec le nombre de personnes qui s’y réfèrent au quotidien.

Points clés à retenir

• Pour analyser un dépôt, faites travailler Codex en lecture seule (/permissions, ou codex exec, en lecture seule par défaut)
• Idéal pour l’onboarding, les audits et l’évaluation de dette technique
• La recherche approfondie de ChatGPT Work convient aux questions multi-sources, comme l’évaluation d’une bibliothèque externe
• Les résultats alimentent des tâches Codex concrètes pour corriger les problèmes
• Relisez chaque rapport : un agent peut se tromper, en particulier sur ce qui manque