--- title: "Systems : la carte derrière la revue inter-dépôts · SourceAnt" description: "Regroupez les dépôts en un système, et une revue peut suivre un changement dans chaque dépôt qu'il atteint. La carte derrière la revue inter-dépôts sur les bases de code multi-dépôts et poly-dépôts." url: "https://sourceant.ai/fr/systems/" --- Revues systèmes et inter-dépôts # Évaluez une modification par rapport à chaque dépôt qu'elle touche. Une pull request épingle un dépôt. Votre modification ne s'arrête pas là. SourceAnt enregistre les services, composants, files d'attente et datastores qui fonctionnent ensemble, puis utilise cette carte pour examiner une modification par rapport à tout ce qu'elle atteint, et nomme les dépôts qu'il n'a pas pu lire plutôt que de les ignorer. [Commencer gratuitement](https://app.sourceant.ai/) [Découvrir le produit](https://sourceant.ai/fr/systems/#reach) Chaque ingénieur et chaque agent inclus, jamais par siège · Vos propres clés de modèle Architecture du système ![Canevas système de SourceAnt montrant les services, datastores et relations proposées](https://sourceant.ai/_astro/systems-canvas-dark.DL1-amif_wKPPF.webp) L'examen ## Une pull request épingle un dépôt. Votre modification ne s'arrête pas là. Chaque outil d'examen lit le diff qui lui fait face. Lorsque le contrat que vous venez de modifier est consommé par un service d'un autre dépôt, le diff est la moitié de l'histoire qui ne peut pas vous le dire. SourceAnt part des fichiers modifiés, parcourt le graphe jusqu'à tout ce qu'ils atteignent, et lit là aussi. ### Ce que la modification atteint À partir des fichiers modifiés, l'examen parcourt le graphe jusqu'aux services, files d'attente et datastores à l'autre extrémité. Les liens approuvés sont énoncés. Les liens en attente sont soulevés comme une question, jamais comme un fait. ### Le code qu'il a lu là-bas Dans chaque dépôt qu'il atteint, il recherche le code qui touche à ce que vous avez modifié et le cite avec le dépôt et la révision dont il provient. Vous pouvez ouvrir le fichier qu'il nomme. ### Ce qu'elle n'a pas pu lire Un dépôt qu'il n'a pas pu atteindre est nommé dans l'examen, avec la raison. Un réviseur qui ignore silencieusement la moitié de votre système est pire qu'un réviseur qui admet la lacune. ### D'où viennent les liens Lus depuis les manifestes que vos dépôts publient déjà, via l'API. Rien n'est cloné, rien n'est exécuté et aucun modèle ne devine. Chaque arête nomme le fichier dont elle provient, et rien n'est approuvé sans une personne. Un référentiel frère est lu à la révision de sa dernière indexation, car une pull request n'épingle que la sienne. Lorsque cette révision est ancienne, la revue le signale plutôt que de la présenter comme actuelle. Comment il le sait ## La carte que parcourt l'examen, et comment il reste honnête Un examen ne peut atteindre que ce que le graphe derrière lui permet. Toute autre carte d'architecture est un instantané pris une fois. Celle-ci est une boucle : lire la source de vérité, proposer la différence, attendre votre décision, et admettre quand elle a vieilli. 1. 01 ### Il lit ce que vos dépôts publient déjà package.json, composer.json, go.mod, requirements.txt et pyproject.toml, récupérés via l'API GitHub. Un manifeste qui ne peut pas être analysé ne propose rien plutôt que de faire échouer l'ensemble du système. 2. 02 ### Il propose, et seulement là où il peut pointer vers un fichier Une dépendance est proposée lorsqu'un dépôt déclare un nom sous lequel un autre dépôt se publie lui-même. Chaque proposition nomme le manifeste dont elle provient, afin que vous puissiez la vérifier en ouvrant un fichier. 3. 03 ### Vous l'approuvez Les propositions arrivent en attente et y restent. Rien ici ne s'approuve de lui-même. Envoyez d'abord persist: false si vous souhaitez voir la proposition sans toucher du tout au graphe. 4. 04 ### Il vous indique quand elle a cessé d'être vraie Un composant jugé obsolète est marqué comme périmé plutôt que supprimé. L'enregistrement indique qu'il est incertain au lieu de se tromper en silence, ce qui est l'échec de tout diagramme d'architecture. Des preuves, pas des affirmations ## Chaque arête montre son travail Une relation que vous ne pouvez pas vérifier est une rumeur. Chacune porte son origine, son degré de certitude et si quelqu'un l'a validée. `billing-api` depends\_on `shared-auth` en attente Statut proposed, approved ou retired. La position du composant, choisie par votre équipe et non par l'analyseur. Confiance 0 à 1. Un composant déclaré par quelqu'un est à 1. Un composant déduit est plus bas, et la raison est enregistrée. Périmé Jugé obsolète. Conservé et signalé plutôt que supprimé, afin que vous puissiez voir ce qui a vieilli et décider. Preuve Le fichier, le manifeste, la révision. Plus le nom exact déclaré et l'écosystème qui l'a émis. confidence 0.6 Un simple nom ne prouve pas que la dépendance vous résout. Un registre public peut porter le même nom, c'est ainsi que fonctionne la confusion de dépendances, donc un nom non détenu est proposé avec une confiance plus faible plutôt qu'affirmé. Délimité à dessein ## Une réponse assez petite pour agir Un parcours renvoie un sous-graphe que vous pouvez inspecter ou transmettre à un modèle. Il vous indique quand il a dû s'arrêter plutôt que de renvoyer silencieusement la moitié d'un graphe. | Champ | Valeur par défaut | Plage | | --- | --- | --- | | profondeur | 2 | 1 à 3 | | direction | les deux | sortant, entrant, les deux | | minimum\_confidence | 0.0 | 0 à 1 | | include\_stale | false | activé ou désactivé | | entity\_limit | 50 | jusqu'à 50 | | relationship\_limit | 100 | jusqu'à 100 | Lisez le graphe directement avec `/api/topology/search` et `/api/topology/traverse`, ou laissez un agent extraire le même sous-graphe via un pack de contexte sur MCP. Pourquoi pas un catalogue ## Un catalogue est une copie saisie par quelqu'un. Ici, tout est lu depuis le code. Les portails développeurs demandent à une personne d'enregistrer chaque service, puis font confiance à cette entrée pour toujours. L'entrée ne se dégrade pas bruyamment. Elle cesse simplement de correspondre au code, et personne ne s'en aperçoit avant un incident. Un catalogue enregistré - Quelqu'un saisit le service une fois - L'exactitude dépend de la mémoire de quelqu'un - La dérive est silencieuse - Aucune trace de la raison pour laquelle une entrée est considérée comme fiable SourceAnt Systems - Lu depuis les manifestes à chaque passage - L'exactitude porte un chiffre sur lequel vous pouvez filtrer - La dérive est marquée comme obsolète - Chaque arête nomme le fichier qui la sous-tend Questions ## Revue inter-dépôts, avec réponse Ce qu'il lit, jusqu'où il va, et ce qu'il fait lorsqu'il ne peut pas y parvenir. ### Qu'est-ce qu'une revue inter-dépôts ? Ce que Systems rend possible. C'est une revue qui ne s'arrête pas au dépôt dans lequel la pull request a été ouverte. Elle part des fichiers modifiés, suit les connexions de votre système jusqu'aux services, files d'attente et datastores situés à l'autre bout, et lit le code à cet endroit. Une revue normale voit un seul diff. Celle-ci voit ce que le diff atteint. ### Est-ce la même chose qu'une revue de code multi-dépôts ? Oui. Revue de code multi-dépôts, revue inter-dépôts et revue poly-dépôts désignent toutes le même problème : le changement est dans un dépôt et la conséquence est dans un autre. Nous parlons de revue inter-dépôts parce que c'est la portée qui compte, pas le nombre de dépôts que vous avez. ### En quoi est-ce différent de l'examen séparé de chaque dépôt ? Examiner chaque dépôt séparément vous donne un verdict par dépôt, sans que personne ne se penche sur ce qui se passe entre eux. C'est là que se trouvent les ruptures : un côté a modifié un contrat que l'autre côté attend encore. Un examen inter-dépôts lit les deux côtés en une seule passe et cite le code lu de l'autre côté, avec le dépôt et la révision dont il provient. ### Comment sait-il quels dépôts sont liés ? Il lit votre code et détermine ce qui va ensemble. Certains liens sont évidents, par exemple lorsqu'un dépôt dépend d'un autre. D'autres ne sont suggérés que par le code. Vous pouvez ajouter d'autres connexions personnalisées et SourceAnt vous présente des suggestions après avoir examiné votre système. ### Fonctionne-t-il sur un monorepo ? Oui. Un monorepo compte comme un seul dépôt, donc une modification en son sein est déjà examinée par rapport au reste. Les systèmes importent davantage dans une configuration multi-dépôts ou polyrepo, où l'autre côté d'une modification se trouve dans un dépôt différent. Ils aident aussi un monorepo qui communique avec quelque chose hors de son propre arbre, comme un service, une file d'attente ou un datastore. Vous pouvez les ajouter comme composants même s'ils n'ont pas de code à lire. ### Un lien doit-il être approuvé avant qu'un examen ne le traverse ? Non. L'examen le traverse que le lien soit approuvé ou non. L'approbation change la manière dont il peut en parler. Un lien approuvé est énoncé comme un fait, avec l'endroit où la modification pourrait casser l'autre côté. Un lien en attente est soulevé comme une question et n'apporte aucune suggestion. ### Que se passe-t-il pour un dépôt qu'il ne peut pas lire ? Il est nommé dans l'examen, avec la raison. Il n'est jamais ignoré en silence. Un réviseur qui ignore silencieusement la moitié de votre système ressemble à celui qui aurait tout lu et n'aurait rien trouvé. Causes habituelles : le dépôt n'a jamais été lu, il est connecté mais pas dans le même système, ou l'application n'y est pas installée. ### Quelle est la fraîcheur du code qu'il lit dans l'autre dépôt ? Un référentiel frère est lu à la révision de sa dernière indexation, car une pull request n'épingle que la sienne. Lorsque cette révision est ancienne, la revue le signale plutôt que de la présenter comme actuelle. La configuration est expliquée pas à pas dans [le guide de revue inter-dépôts](https://sourceant.ai/fr/docs/cross-repository-reviews). ### À emporter avec vous Les instantanés de graphe sont portables, transmis en flux et validés à l'entrée, et une écriture interrompue est récupérée plutôt que laissée à moitié appliquée. ### Délimité, et uniquement à son propre périmètre Sur MCP, le périmètre est le principal authentifié. Sur HTTP, c'est une revendication d'espace de travail sur le jeton, et un jeton sans cette revendication est refusé. ### Votre vocabulaire, pas le nôtre Une partie est ce que votre architecture appelle une partie : un service, une file d'attente, un magasin de données, une tâche. SourceAnt ne vous impose aucune liste de types. ## Connectez deux dépôts et lisez une seule revue Pointez-le vers des dépôts que vous possédez déjà, approuvez la première proposition, puis ouvrez une modification sur l'un d'eux et voyez ce que la revue atteint sur l'autre. [Commencer gratuitement](https://app.sourceant.ai/) [Lire la documentation](https://sourceant.ai/fr/documentation)