Claude Opus 4.7 peut-il analyser un dépôt entier en une seule fois ?

Mais une fenêtre de contexte n’est pas un conteneur réservé uniquement au code source. Elle inclut tout ce que le modèle doit « voir » pour répondre :

• le prompt système et les consignes ;
• la demande utilisateur ;
• l’historique de conversation ;
• les fichiers du dépôt ;
• les résultats de recherche, logs, traces d’erreur ou sorties de tests ;
• les éventuelles réponses précédentes ;
• et la place nécessaire pour produire la réponse finale.

Autrement dit, si vous remplissez toute la fenêtre avec des fichiers, il ne reste plus assez d’espace utile pour une analyse détaillée, un plan de correction, un rapport d’audit ou un patch conséquent. Or Opus 4.7 peut produire jusqu’à 128k tokens en sortie : il faut donc prévoir cette marge dès le départ.

Pourquoi « tout le repo » n’est pas toujours une bonne idée

Un dépôt de code n’est presque jamais un document propre et linéaire. Il peut contenir du code source, des tests, des fichiers de configuration, de la documentation, des dépendances vendorisées, des fichiers générés, des artefacts de build, des caches, des logs volumineux ou des fichiers dupliqués.

Mettre tout cela tel quel dans le contexte peut être techniquement possible pour un petit ou moyen dépôt. Mais dans un gros projet, surtout un monorepo, cela risque de consommer une grande partie des 1M tokens avec du bruit : code généré, dépendances externes, résultats compilés ou journaux sans intérêt direct. Le modèle aura alors moins de place pour les fichiers réellement importants et pour sa réponse.

C’est d’autant plus important avec Opus 4.7 qu’Anthropic signale un nouveau tokenizer : pour un même texte, il peut utiliser environ 1x à 1,35x tokens par rapport aux modèles précédents, selon le contenu. L’endpoint /v1/messages/count_tokens peut donc donner un résultat différent avec Opus 4.7 qu’avec Opus 4.6.

En clair : une estimation faite avec un ancien modèle, ou à la louche à partir du nombre de lignes, peut être trop optimiste.

Ce que disent les sources officielles

« Stable » ne veut pas dire « magique »

Anthropic positionne Opus 4.7 pour des usages exigeants : workflows agentiques complexes, travail de longue durée et codebases plus grands. Son annonce officielle affirme aussi que le modèle peut traiter des tâches complexes et longues avec rigueur et constance.

Ces éléments permettent de dire une chose raisonnable : Opus 4.7 est conçu pour mieux gérer les longues tâches de développement et les grands contextes que des modèles plus limités.

Ils ne permettent pas de conclure que n’importe quel dépôt, n’importe quel agent loop ou n’importe quel document massif sera analysé parfaitement en une seule passe. Pour un usage sérieux — audit de sécurité, migration de framework, correction automatique dans une CI/CD, gros refactoring — il faut encore valider le comportement sur le vrai dépôt, avec les vrais tests et les vrais cas d’échec.

Méthode recommandée pour analyser un dépôt complet

1. Commencer par une carte du dépôt

Avant de charger des milliers de fichiers, demandez ou générez une vue d’ensemble : arborescence, langages utilisés, points d’entrée, dossiers de tests, fichiers de configuration, dépendances, modules critiques et changements récents.

Cela permet de décider quels fichiers doivent vraiment entrer dans le contexte.

2. Exclure le bruit

Dans la plupart des dépôts, il vaut mieux ignorer au départ :

• les dossiers node_modules, vendor ou équivalents ;
• les fichiers générés ;
• les artefacts de build ;
• les caches ;
• les gros logs ;
• les binaires ;
• les fichiers dupliqués ou minifiés.

Le but n’est pas de réduire le contexte pour le plaisir, mais de donner au modèle les informations les plus utiles.

3. Recompter les tokens avec Opus 4.7

Ne vous fiez pas à une estimation faite pour Opus 4.6 ou un autre modèle. Anthropic indique que le nouveau tokenizer d’Opus 4.7 peut utiliser environ 1x à 1,35x tokens pour le même texte, et que /v1/messages/count_tokens renverra un nombre différent de celui d’Opus 4.6.

C’est une étape indispensable si vous essayez de faire tenir un dépôt complet dans une seule requête.

4. Garder une vraie marge de sortie

Même si tout le dépôt tient dans 1M tokens, il ne faut pas forcément remplir la fenêtre jusqu’au bord. Une bonne analyse de code doit souvent produire :

• une synthèse de l’architecture ;
• une liste de risques ;
• des hypothèses ;
• des fichiers à modifier ;
• une stratégie de tests ;
• parfois un patch détaillé.

Opus 4.7 prend en charge jusqu’à 128k tokens de sortie, mais cette capacité doit être anticipée dans la conception de la requête.

5. Pour les gros projets, préférer une approche par étapes

Pour un grand dépôt ou un monorepo, la méthode la plus robuste consiste souvent à procéder en plusieurs temps :

1. compréhension de l’architecture générale ;
2. identification des modules concernés ;
3. lecture ciblée des fichiers clés ;
4. recherche des références et dépendances ;
5. analyse des tests et logs d’erreur ;
6. proposition de correction ;
7. validation par tests.

Cela correspond mieux au positionnement d’Opus 4.7 comme modèle adapté aux workflows agentiques complexes et aux codebases plus grands.

6. Demander au modèle de déclarer sa couverture

Pour éviter une fausse impression de maîtrise totale, il est utile d’exiger une section explicite dans la réponse :

• fichiers réellement lus ;
• fichiers ignorés ;
• hypothèses ;
• zones d’incertitude ;
• risques ;
• tests à lancer ;
• points nécessitant une revue humaine.

Ce n’est pas une garantie d’exactitude, mais cela rend l’analyse plus vérifiable.

Verdict

Claude Opus 4.7 peut, dans certains cas, analyser un repo entier en une seule requête : sa fenêtre de contexte de 1M tokens et sa sortie maximale de 128k tokens le rendent nettement plus adapté aux grands contextes que les modèles plus contraints.

Mais le chiffre « 1M » ne suffit pas. Il faut compter tout le contexte réel, laisser de la place pour la réponse, utiliser le tokenizer d’Opus 4.7 pour estimer correctement les tokens, et éviter de gaspiller la fenêtre avec des fichiers inutiles.

Pour un petit ou moyen dépôt bien nettoyé, une passe complète peut être réaliste. Pour un grand monorepo, un dépôt rempli de fichiers générés, ou une tâche nécessitant une analyse profonde et de gros correctifs, la voie la plus fiable reste une approche structurée : trier, compter, charger par étapes, vérifier par les tests, puis itérer.