Vocabulaire

Un petit glossaire des mots que vous verrez dans l'application. Chacun veut dire exactement ce qu'il dit — pas de complexité cachée.

• Conversation — L'endroit où vous décrivez ce que vous voulez, en langage naturel. Comme discuter avec un développeur particulièrement doué pour lire entre les lignes d'un cahier des charges. Une conversation peut rester informelle indéfiniment, ou être promue en mission quand elle est suffisamment concrète.

• Mission — L'unité de travail complète pour un changement concret — le plus souvent une conversation devenue assez précise pour être promue. Une mission vit sur sa propre branche durable et porte les runs qui construisent le changement. Et elle reste conversable : chaque mission a son propre chat, où vous pouvez demander où ça en est ou la réorienter en cours de route.

• Workflow — Un plan réutilisable et versionné, dessiné comme un graphe de nœuds dans l'éditeur visuel. Un workflow n'exécute rien par lui-même : vous l'attachez à une mission, et c'est là qu'il tourne.

• Run — Une exécution d'un workflow au sein d'une mission, sur sa propre branche. Vous examinez le résultat de chaque run — le diff — et vous l'acceptez ou l'écartez ; l'accepter l'intègre à la mission. Voir États du cycle de vie.

• Tâche — Un nœud du plan en cours d'exécution, matérialisé en unité de travail de coder. Une tâche est un instantané d'exécution que vous pouvez inspecter : le résultat, le diff, ce que ça a coûté, combien de tentatives il a fallu.

• Changement — Le delta réversible qu'un run accepté ajoute à la mission. La merge request de la mission est la composition de ses changements acceptés, et chacun peut être annulé individuellement (ce qui a été construit par-dessus suit, après confirmation).

• Coder — L'agent IA qui fait le travail. Chaque coder tourne dans son propre conteneur, avec le modèle et les outils dont il a besoin, et pousse ses résultats vers le miroir de revue. Les coders existent en trois variantes (standard, browser, android) — les files dans lesquelles ARDS met en attente et dimensionne les conteneurs — et une tâche peut en plus puiser dans des pools de capacités partagés (un vrai navigateur, un émulateur Android, un environnement Windows). Voir Comment travaillent les coders.

• Revue / portail d'approbation — L'étape avec un humain dans la boucle. Les coders poussent vers un miroir de revue — une copie séparée de votre dépôt — et rien n'arrive dans votre dépôt réel tant que vous n'avez pas approuvé. Vous approuvez ou rejetez chaque lot.

• Demande d'attention (attention request) — Un signal du système indiquant qu'une personne est nécessaire. La plupart viennent des missions (« approuvez ce plan », « répondez à cette clarification ») mais elles peuvent aussi se déclencher quand un coder se bloque ou qu'une clé d'API échoue. Les demandes d'attention sont remontées dans le tableau de bord et par email.

• Modification — Un changement qui a été approuvé et fusionné jusqu'à votre dépôt d'origine. La page Modifications est la trace de « ce qui a réellement atterri ». Avec le modèle des runs, chaque run accepté atterrit comme un changement réversible, et la merge request est leur composition.

• Produit — Une couche de regroupement prévue au-dessus des projets. Pas en v1 : aujourd'hui, le sommet de l'arbre que vous toucherez réellement est le projet/workspace. Si vous croisez le mot « produit » dans ces docs ou dans une sortie de chat, lisez-le comme « un futur regroupement de projets » — rien dans l'UI actuelle ne pointe vers un produit.

• Workspace / projet — Un dépôt qu'ARDS connaît. Vous en enregistrez un depuis la page Projects ; vous pouvez en ajouter ou en changer là plus tard. Chaque workspace a son propre miroir de revue.

• GitMirror — Le service interne qui héberge les clones côté revue. Vous verrez « le miroir » dans les messages et les écrans de revue ; c'est GitMirror.

• Fournisseur (Provider) — Un fournisseur d'IA que vous avez connecté : Anthropic, compatible OpenAI, Synthetic.new, etc. Les fournisseurs portent les clés d'API ; plusieurs fournisseurs peuvent être connectés simultanément.

• Modèle — Un LLM précis vers lequel router le travail : claude-opus-4-7, claude-haiku-4-5, hf:Qwen/Qwen3-Coder-480B-A35B-Instruct, etc. Modèles différents pour usages différents — voir Modèles, fournisseurs et coûts.

• Instructions de node (node instructions) — Chaque node de workflow peut porter des instructions supplémentaires superposées à son prompt. Vous les définissez à la main — par run, par projet, par tenant, ou globalement ; la plus spécifique gagne. Qu'ARDS propose de lui-même un meilleur prompt n'est pas en v1 ; si ça arrive un jour, la proposition arrivera comme une décision que vous approuvez ou refusez — rien ne s'appliquera jamais tout seul.

Voilà le vocabulaire de base. Quelques termes supplémentaires existent sur les pages avancées (l'orchestrateur, Ghost, Cycle) — voir Avancé. Lecture optionnelle.