Lire toute la base de code au-delà de la fenêtre de contexte

Un modèle qui accepte un million de lignes n'est pas pour autant capable de comprendre un système d'un million de lignes. La capacité indique si le texte tient dans la fenêtre. Elle ne dit pas si le modèle trouvera la bonne définition, reliera un appelant indirect à un effet de bord ou remarquera qu'une étape JCL change le sens du programme COBOL qu'elle lance.

Cette distinction compte surtout lors de la réécriture d'un système ancien. Une traduction locale plausible peut compiler tout en cassant la clôture mensuelle, car l'ancien comportement se répartit entre fichiers source, copybooks, déclencheurs de base de données, contrôle des jobs, validation des écrans et conventions de production. Tout placer dans un seul prompt remplace un problème d'omission par un problème de discrimination. La réponse figure dans le contexte, mais le modèle n'a pas de structure fiable pour décider quels faits gouvernent la modification.

Lire toute la base de code relève donc de l'architecture du système, pas de la taille du prompt. Il faut un modèle durable du dépôt, un parcours explicite des dépendances, un raisonnement par étapes et des preuves exécutables que le système produit se comporte comme l'ancien.

Une fenêtre de contexte mesure la capacité, pas la compréhension

Une longue fenêtre de contexte indique l'entrée maximale qu'un modèle peut accepter dans des conditions données. Elle ne promet ni un rappel uniforme, ni un raisonnement stable dans toute la fenêtre, ni des raccords corrects entre des faits très éloignés. Ce sont des capacités distinctes. Les réduire à une seule mesure constitue la première erreur de conception.

Nelson Liu et ses coauteurs ont rendu le problème de position concret dans l'article Lost in the Middle. Pour les questions sur plusieurs documents et la récupération de paires clé-valeur, les performances culminaient souvent lorsque les éléments pertinents figuraient au début ou à la fin de l'entrée. Elles baissaient lorsque ces mêmes éléments passaient au milieu. L'article ne prouve pas que tous les modèles actuels échouent sur tous les longs programmes. Il prouve qu'une ingestion réussie mesure mal la fiabilité d'utilisation.

Le code complique la tâche par rapport à la prose. Un dépôt contient des milliers de formes répétées: accesseurs, validateurs, structures d'enregistrement, branches d'erreur, fichiers générés et étapes batch presque identiques. Le modèle doit distinguer des faits qui se ressemblent tout en suivant des relations qui ne sont jamais voisines dans le texte. Un paragraphe CALCULATE-TAX et un paragraphe CALCULATE-TAX-OLD peuvent partager presque tous leurs tokens et avoir des appelants différents. La similarité aide à trouver les deux. Elle ne dit pas lequel gouverne la transaction.

Le nombre de tokens masque aussi le coût des représentations. Le texte source n'est qu'une couche. Une analyse utile demande l'identité des symboles, les arêtes d'appel, les flux de données, les métadonnées de build, les schémas, la configuration, les tests et les observations du logiciel en fonctionnement. Si un fournisseur affirme que sa fenêtre contient le dépôt, demandez ce qui a été exclu, comment les fichiers ont été ordonnés, comment les liens entre langages ont été encodés et comment le système teste ses affirmations. La taille de la fenêtre ne répond à rien de cela.

Le test de réception pratique est simple: déplacez le fichier décisif, ajoutez des fichiers non pertinents mais similaires et répétez la tâche. Si la réponse change, le système a lu une séquence et non une base de code.

Un autre test porte sur la composition. Demandez l'origine d'un champ, où il change et quel effet externe dépend de sa valeur finale. Posez ensuite ces questions séparément et comparez le chemin recomposé. Un lecteur qui répond à chaque question locale sans conserver l'identité le long de la chaîne sait chercher, mais il ne comprend pas le système. Cette défaillance passe facilement inaperçue, car chaque réponse isolée paraît juste.

La récupération rate les relations sans vocabulaire commun

La récupération de fragments convient aux questions dont la réponse ressemble à la requête. Or le comportement d'un programme dépend souvent de relations plutôt que de mots communs. L'appelant peut employer un nom générique, faire une répartition par table, construire un nom de procédure, publier un événement, invoquer une procédure stockée ou confier la main à un ordonnanceur. Une recherche vectorielle sur le concept métier peut trouver l'appelé tout en ratant l'appelant qui fournit l'indicateur décisif.

Prenons une règle de facturation en COBOL. Le paragraphe visible lit une classe de compte et calcule des frais. Une étape JCL choisit un autre jeu de données d'entrée le dernier jour ouvré. Un copybook superpose deux champs de l'enregistrement, et un déclencheur PL/SQL supprime les frais pour les comptes migrés. Aucun de ces artefacts n'a besoin de reprendre les mots du ticket. Récupérer uniquement le paragraphe produit une fonction TypeScript propre et fausse.

SWE-bench a saisi un fait voisin à plus petite échelle: les corrections réelles exigent souvent des changements coordonnés entre fonctions, classes et fichiers. Son dispositif initial comparait la récupération avec l'accès aux fichiers modifiés par le correctif humain. C'est un avertissement utile. Une meilleure génération ne peut pas retrouver les preuves que l'étape de récupération n'a jamais fournies, et une migration en cours ne dispose pas d'un ensemble de fichiers oracle.

Le métier confond aussi le rappel de recherche et la complétude comportementale. Le premier demande si un élément pertinent connu figure parmi les résultats. La seconde demande si le système a trouvé tous les artefacts nécessaires pour expliquer un résultat observé. Des fragments étiquetés permettent de mesurer le premier. Seuls le traçage et les tests peuvent établir la seconde.

Un lecteur de dépôt doit réunir plusieurs voies dans le même magasin de preuves:

• la recherche lexicale pour les identifiants exacts, littéraux, noms d'enregistrement et codes d'erreur;
• la recherche sémantique pour les concepts formulés avec un autre vocabulaire;
• la résolution de symboles et le parcours des appels pour la structure explicite;
• les arêtes de flux de données et de schéma pour les valeurs qui franchissent les procédures;
• les traces d'exécution pour la répartition dynamique, la configuration et les effets externes.

Ces cinq voies ne sont pas des moteurs concurrents. Chacune révèle une catégorie de panne différente. Le système doit conserver la raison de sélection d'un artefact, l'arête qui y a mené et les questions non résolues. Un sac de fragments classés sans provenance pousse le modèle à transformer une confiance de récupération en certitude inventée.

Les limites de fragments créent une autre perte silencieuse. Une déclaration de procédure peut tomber dans un fragment, tandis que sa précondition, son gestionnaire d'erreur ou sa définition de données voisine tombe dans un autre. Agrandir les fragments garde plus de contexte local, mais réduit la précision et consomme davantage de prompt. Le chevauchement copie du texte sans rétablir la structure du programme. Les fragments fondés sur le parseur améliorent le compromis, mais même une fonction complète ne montre pas une condition d'ordonnanceur ou l'effet d'un déclencheur ailleurs. Après le premier résultat, la récupération doit étendre le graphe. Elle doit s'arrêter selon les questions résolues et non selon un top-k arbitraire.

La dilution de l'attention résiste à un prompt plus grand

Ajouter des éléments pertinents peut dégrader une réponse lorsque le modèle doit choisir parmi trop de faits plausibles. Pour l'ingénieur, la dilution de l'attention signifie que la preuve décisive entre en concurrence avec le code répétitif, les implémentations dupliquées, les branches mortes, le code généré, les commentaires d'une ancienne version et les tests d'un comportement périmé.

Une recommandation courante consiste à placer tout le dépôt dans le prompt et à demander au modèle de l'examiner soigneusement. Elle plaît parce qu'elle supprime un composant visible de la chaîne. Aucun index n'est à régler et aucun moteur de récupération ne peut être blâmé. Cette simplicité est cosmétique. Le modèle effectue toujours une sélection, mais dans une inférence opaque où l'on ne peut ni examiner les candidats ratés ni rejouer un parcours.

L'ordre du dépôt devient alors une politique accidentelle. L'ordre alphabétique favorise certains modules. La concaténation selon les dépendances nécessite un graphe avant le prompt, ce qui reconnaît le besoin d'analyse. Placer les fichiers probables aux deux extrémités exploite un motif de benchmark au lieu d'établir la compréhension. Répéter les fichiers importants gaspille la capacité et peut surpondérer des doublons périmés.

LongBench v2 incluait la compréhension de dépôts parmi ses tâches à très longue entrée et a montré que la réponse directe restait difficile. Sa leçon méthodologique est plus intéressante: le temps de raisonnement et l'effort d'inférence peuvent compter autant que la taille d'entrée annoncée. Une architecture de migration doit aller plus loin et externaliser le travail intermédiaire. Elle ne doit pas demander à une même génération de découvrir le système, décider de la cible, produire le code et certifier la parité.

Une petite évaluation suffit à exposer la dilution. Choisissez une modification dont les faits déterminants couvrent un appelant, une valeur de configuration et un effet de bord. Exécutez-la avec le minimum de preuves, puis ajoutez dix groupes de distractions plausibles tirées du même dépôt. Enregistrez le chemin d'appel annoncé, les symboles cités, le correctif et le résultat des tests à chaque essai. Le but n'est pas de calculer un score universel. Il est de voir si le contexte ajouté change le récit du comportement sans aucune modification du programme.

Les résumés de prompt ne guérissent pas seuls ce problème. Résumer revient à décider avec perte de ce qui sera pertinent avant de connaître la tâche ultérieure. Un résumé rédigé pour découvrir l'architecture peut omettre une règle d'arrondi nécessaire à la correction d'un défaut. Gardez les résumés comme outils d'orientation, attachez-les aux entités source décrites et autorisez la tâche à rouvrir les preuves d'origine. Un résumé ne doit jamais devenir le seul récit restant d'un module.

Le dépôt a besoin d'une carte typée avant la génération

L'analyse de toute la base commence par une représentation typée et interrogeable du système. Un index vectoriel plat est utile dans cette représentation, mais il ne peut pas en tenir lieu. L'unité durable est une entité dotée d'une identité, d'un emplacement, d'un langage et d'arêtes vers les autres entités.

La carte doit au minimum représenter les fichiers, symboles, points d'entrée, appels, lectures et écritures, schémas, jobs, écrans, tests, clés de configuration et interfaces externes. Les arêtes doivent être typées, car calls, loads dynamically, writes field et runs after impliquent des raisonnements différents. La confiance et l'origine appartiennent à chaque arête. Une arête d'appel issue du compilateur ne doit pas ressembler à une association déduite par le modèle.

Dans les dépôts anciens, les frontières entre langages font partie de la sémantique. JCL choisit programmes et jeux de données. Les cartes CICS relient écrans et champs. Les programmes RPG dépendent de fichiers d'affichage. Les formulaires VB6 contiennent un câblage d'événements hors des procédures ordinaires. Classic ASP mélange balisage, script, état de session et accès à la base. Les packages PL/SQL peuvent cacher des effets derrière déclencheurs et synonymes. Un parseur du langage principal ne voit qu'une partie du système exécutable.

La carte a aussi besoin des faits négatifs et non résolus. Si une cible d'appel dynamique ne peut pas être résolue statiquement, conservez l'expression et les candidats au lieu d'en choisir un en silence. Si deux copybooks définissent le même nom d'enregistrement selon des options de build différentes, gardez les deux variantes et leur condition de sélection. Les inconnues doivent devenir des demandes de trace ou des cas de parité, jamais des suppositions en prose.

Un enregistrement de preuve compact pourrait ressembler à ceci:

{
  "claim": "late fee is suppressed for migrated accounts",
  "path": ["BILLJOB", "FEE-CALC", "ACCT_FEE_TRIGGER"],
  "evidence": ["jobs/bill.jcl:88", "src/fee.cbl:412", "db/account.sql:219"],
  "conditions": ["RUN_MODE=MONTH_END", "account.migrated=true"],
  "unresolved": ["dynamic dataset alias at BILLIN"]
}

Cet enregistrement n'est pas une astuce de prompt. C'est une affirmation inspectable qu'une autre étape peut contester. Lorsque la génération change FEE-CALC, le système peut trouver les points d'entrée touchés, demander la liaison de jeu de données non résolue et choisir les tests qui exercent la condition. Sans la carte, chaque prompt doit redécouvrir ces faits et les redécouvrira différemment.

La représentation doit aussi être versionnée. Code produit, commits source, instantanés de schéma et traces enregistrées ont besoin d'une même limite de révision. Sinon, le graphe peut relier l'appelant de mardi à un appelé remplacé mercredi et décrire un système qui n'a jamais existé. L'analyse incrémentale doit invalider les arêtes dérivées lorsque leur source change, puis recalculer les affirmations dépendantes. Réutiliser un cache sans provenance est rapide jusqu'au jour où il certifie le mauvais build.

La lecture de toute la base doit avancer par étapes

Un lecteur fiable sépare découverte, modélisation du comportement, conception cible, implémentation et vérification. Les étapes peuvent boucler, mais chacune produit des artefacts qui contraignent la suivante. Une génération fluide ne peut donc pas effacer une incertitude découverte auparavant.

La découverte inventorie les langages, chemins de build, points d'entrée, schémas, jobs et frontières externes. Elle analyse ce qui peut l'être, consigne les échecs et relie les artefacts entre langages. Elle produit une carte du dépôt et une liste explicite des angles morts.

La modélisation du comportement part des opérations observables plutôt que des fichiers. Pour chaque point d'entrée, le système suit conditions, transitions d'état, sorties et effets de bord. Il regroupe les chemins dupliqués qui appliquent la même règle et sépare les chemins similaires aux préconditions différentes. Le résultat est un ensemble d'affirmations comportementales liées à leurs preuves.

La conception cible décide ensuite où ces comportements doivent vivre dans des services Go, des noyaux Rust, des clients TypeScript ou Postgres. C'est là qu'une réécriture diffère d'une translittération. Une conversion d'un paragraphe en une fonction peut préserver le contrôle tout en reconduisant état global, couplage aux fichiers et hypothèses d'ordonnancement. La conception doit préserver le comportement à la frontière tout en changeant volontairement la structure interne.

L'implémentation consomme des lots de travail bornés issus de la carte. Un lot contient le comportement cible, les entités source utiles, les appelants en amont, les effets en aval, les contraintes, les inconnues et les cas de parité exigés. Le modèle peut demander plus de preuves. Il ne doit jamais combler une arête absente par une supposition assurée.

La vérification tourne en continu, pas après une fusion finale héroïque. Les échecs mettent à jour le modèle comportemental ou révèlent un défaut de la cible. Cette boucle compte, car la seule analyse source ne peut pas décider si une branche étrange est morte, encode une exception réglementaire ou n'est atteinte que par des données de production.

Cette conception par étapes consacre l'attention du modèle à une tâche définie. Les modèles savent interpréter du code désordonné et proposer des implémentations. Le système qui les entoure fournit identité, mémoire, parcours et un juge qui ne note pas la prose.

La revue humaine doit suivre les mêmes artefacts. Les ingénieurs doivent examiner les comportements contestés et les contrats cibles, pas parcourir des milliers de lignes produites dans l'espoir de repérer un changement sémantique. Une étape peut avancer lorsque ses affirmations ont des preuves, ses inconnues ont un responsable et les contrôles exigés existent. L'approbation d'une prose soignée n'a aucune place dans ce passage.

Les preuves d'exécution trouvent ce que l'analyse statique rate

L'analyse statique décrit les comportements possibles. L'exécution enregistrée montre ceux qui ont réellement eu lieu pour certaines entrées. Une réécriture sérieuse a besoin des deux, car chacune couvre les angles morts de l'autre.

L'analyse statique peut énumérer des branches qu'aucun enregistrement n'a atteintes. Elle peut trouver une écriture dans un chemin d'erreur, un batch trimestriel ou une action d'écran absente du trafic récent. Les traces d'exécution résolvent les appels dynamiques, les vraies valeurs de configuration, les alias de jeux de données, le SQL produit à l'exécution et l'ordre des effets externes. Aucune source ne doit devenir toute la vérité.

Les équipes proposent souvent de remplacer cela par la couverture de tests. Les tests existants sont des preuves utiles, mais les vieux systèmes ont souvent des suites unitaires étroites, des scripts d'intégration dépendants de l'environnement ou aucun test automatisé autour des comportements qui font tourner l'activité. Réussir ces tests prouve la compatibilité avec les tests, pas avec la production.

Un banc de parité donne une forme concrète à la comparaison. Capturez une entrée à une frontière stable, rejouez-la sur l'ancienne et la nouvelle implémentation, normalisez les valeurs non déterministes et comparez les sorties avec les effets de bord. Un résultat peut être exprimé sans interprétation:

case: invoice/month_end/migrated_account
old: status=200 body_sha256=7c... ledger_rows=0 notices=1
new: status=200 body_sha256=7c... ledger_rows=1 notices=1
verdict: FAIL side_effect.ledger_rows expected 0 got 1

Cet échec renvoie à l'affirmation sur la suppression des frais et à son chemin de preuve. L'équipe peut vérifier si le nouveau code a raté le comportement du déclencheur, si la configuration de rejeu n'a pas marqué le compte comme migré ou si la normalisation a caché une différence source. Une assertion générique telle que «les sorties diffèrent» renverrait le modèle fouiller le dépôt entier.

Le trafic enregistré exige des précautions. Les secrets et données personnelles doivent être traités selon l'environnement, et les effets destructifs isolés ou virtualisés pendant le rejeu. La couverture demande aussi un inventaire: quels points d'entrée, périodes métier, types d'erreur et variantes de configuration figurent dans le corpus? Un million de requêtes heureuses répétées ne couvre pas la rare procédure de clôture.

Les règles de comparaison méritent la même attention que les entrées capturées. Horodatages, identifiants produits, lignes non ordonnées et chemins propres à l'environnement peuvent nécessiter une normalisation, mais chaque règle soustrait une différence possible à l'observation. Stockez chaque règle sous forme de code, expliquez pourquoi elle est sûre et testez qu'elle ne masque aucun changement significatif. Si un autre batch consomme les enregistrements anciens dans leur ordre, les trier avant comparaison fabriquerait une fausse parité.

La lecture parallèle exige un état partagé

Répartir un dépôt entre des agents ne réduit le temps écoulé que s'ils écrivent dans un modèle commun et cohérent du système. Dix résumés indépendants produisent dix vocabulaires, des conclusions en double et des trous aux frontières que chaque intervenant croyait confiées à un autre.

Les travailleurs parallèles doivent prendre en charge des régions du graphe ou des questions explicites. L'un peut résoudre les liens entre jobs et programmes, un autre cartographier les effets de base de données et un troisième classer les points d'accès externes. Chacun écrit entités, arêtes typées, preuves et conflits dans le même magasin. L'identité des entités doit rester stable pour reconnaître que CUSTOMER-REC dans un copybook et le tampon transmis par trois programmes décrivent la même structure sous la même condition de build.

Les conflits sont une sortie utile. Si l'analyse statique indique qu'un appelant atteint une procédure, mais que les traces montrent une seconde voie dynamique, le système doit conserver les deux et programmer leur résolution. Si deux agents donnent des sens métier différents au même champ, un relecteur verra le désaccord avant que le code produit ne grave l'une des interprétations.

La concurrence demande aussi un ordonnancement conscient des dépendances. Produire le remplacement d'un module aval alors que son contrat d'entrée reste contesté a peu d'intérêt. Les composants indépendants peuvent avancer, mais les changements qui franchissent une arête non résolue doivent attendre ou porter des interfaces explicitement provisoires.

L'affirmation du million de lignes ne devient crédible qu'avec ce modèle. CodeHero lit en parallèle tous les langages de l'arbre et utilise une représentation commune du système entier au lieu de traiter chaque prompt comme une séance de lecture isolée. Ce fait d'architecture compte. Le nombre d'agents simultanés ne dit rien, à lui seul, sur la compréhension.

L'interface de revue doit montrer comment une conclusion a été assemblée: emplacements source, chemin du graphe, cas de trace, interprétations concurrentes et code aval qui la consomme. Une barre de progression pour dirigeant ne suffit pas à l'ingénieur qui doit décider si une règle de paiement a survécu à la réécriture.

Un état partagé ne signifie pas un prompt immense partagé entre tous les travailleurs. Il signifie un magasin transactionnel de preuves avec des identifiants stables et des contrôles de version. Les travailleurs peuvent traiter des tranches bornées, puis fusionner les faits uniquement si la révision source correspond encore. On évite ainsi les agents isolés qui s'oublient et la conversation globale qui enfle jusqu'à ce que personne ne sache quelle affirmation reste actuelle.

Qualité de l'architecture et parité sont deux portes distinctes

Une réécriture peut reproduire le comportement observé tout en reconduisant mal l'ancienne architecture. Elle peut aussi paraître moderne tout en modifiant les frontières du système. Ce sont deux portes distinctes, et aucune ne doit compenser l'autre.

La parité comportementale évalue requêtes, fichiers, messages, changements en base, ordre temporel pertinent et erreurs. La revue d'architecture évalue frontières des modules, propriété de l'état, idiomes du langage cible, traitement des pannes, observabilité, déploiement et suppression des vieux couplages. Un score pondéré qui mélange les deux peut cacher un défaut fatal. Exigez le passage de chaque porte.

Les démonstrations de dépôt brouillent souvent cette distinction. Produire du Go syntaxiquement correct à partir de COBOL montre une traduction. Remplacer un état couplé au batch par des services explicites tout en préservant le comportement de clôture montre une modernisation. La seconde demande la carte du dépôt, les contraintes opérationnelles et les preuves de parité. La génération de code seule ne peut pas l'établir.

Fixez les critères de revue avant l'implémentation. Pour une frontière de service, consignez les appelants permis, contrats de requête et réponse, propriété transactionnelle, comportement de reprise et cas de parité. Pour un noyau numérique Rust, consignez domaines d'entrée, arrondi, débordement et vecteurs de référence. Pour un client TypeScript, consignez la responsabilité de la validation et son application côté serveur. Ce sont des décisions d'ingénierie, pas des détails à déduire du fragment source arrivé en tête.

N'acceptez pas «le modèle a vu tout le dépôt» comme preuve pour l'une ou l'autre porte. Demandez le chemin du point d'entrée au comportement modifié, les arêtes non résolues de ce chemin, la décision cible qui remplace l'ancien couplage et les cas de rejeu réussis. Si le système ne produit pas ces quatre éléments, il a produit du code sans explication défendable du système.

L'équivalence opérationnelle peut couvrir davantage que le corps des réponses. Heures limites de batch, ordre des verrous, frontières de reprise, modes d'arrondi, encodages de fichier et heure d'envoi des messages peuvent faire partie du contrat lorsqu'un autre système en dépend. L'inventaire comportemental doit indiquer quelles propriétés correspondent exactement, lesquelles peuvent varier dans une limite et quels changements ont été approuvés par leur responsable. Traiter chaque différence comme un bogue bloque la modernisation. Qualifier chaque différence gênante d'amélioration abandonne la parité.

Évaluez le lecteur en perturbant les preuves

La meilleure évaluation d'un lecteur de dépôt teste sa stabilité sous des changements qui ne devraient pas influer sur la réponse. Une seule démonstration réussie dit peu, car l'ordre des fichiers, la formulation de la requête et les fragments choisis ont pu favoriser le cas.

Constituez un jeu de questions sur le dépôt dont les réponses s'appuient sur plusieurs artefacts. Incluez appels directs, répartition dynamique, variantes choisies par configuration, effets de base, ordre batch, code mort ressemblant au code actif et frontières de langage. Pour chaque question, consignez le chemin de preuve attendu, pas seulement une réponse en prose.

Perturbez ensuite l'entrée de façon contrôlée:

1. Réordonnez les fichiers et les résultats de parcours sans changer le contenu.
2. Ajoutez des implémentations mortes presque identiques et des commentaires périmés.
3. Renommez les identifiants locaux en préservant structure et comportement.
4. Retirez un artefact requis et vérifiez que le système signale l'incertitude.
5. Ajoutez une trace d'exécution qui contredit l'hypothèse statique.

Notez séparément le rappel des preuves, la justesse du chemin, le traitement de l'incertitude, la modification produite et le résultat de parité. Un lecteur qui atteint la bonne réponse par le mauvais chemin reste fragile. Un système qui refuse de conclure après le retrait d'une preuve peut être meilleur que celui qui maintient sa réponse initiale.

Le coût et la latence appartiennent à l'évaluation, mais ils ne remplacent pas la précision. Mesurez temps d'analyse, coût de mise à jour de l'index, parcours du graphe, appels au modèle, temps de rejeu et temps de revue humaine. Les changements incrémentaux doivent mettre à jour les entités et tests touchés au lieu de forcer une relecture complète. Ainsi, lire toute la base devient une architecture exploitable plutôt qu'une démonstration de lancement coûteuse.

La question de réception n'est pas de savoir si un appel de modèle peut contenir un million de lignes. Il faut savoir si le système explique un comportement, résiste au contexte inutile, expose les preuves manquantes, produit une conception cible délibérée et prouve la nouvelle implémentation face à l'ancienne. Une fenêtre plus grande peut aider à plusieurs endroits. Elle ne supprime jamais les mécanismes qui l'entourent.