Conventions utilisées dans le document

La documentation du Projet Horizon présente simultanément des systèmes existants, des décisions de conception, des fonctionnalités envisagées et des objectifs à plus long terme. Des conventions communes sont utilisées afin de distinguer clairement ces différents niveaux.

Les statuts présentés dans ce chapitre indiquent principalement le degré de définition ou de validation d’un élément. Ils ne décrivent pas son état de développement.

Décision et réalisation

Une fonctionnalité peut être validée sans avoir encore été développée. À l’inverse, un système peut appartenir à l’état actuel tout en constituant seulement une solution temporaire destinée à être remplacée par Horizon.

Statuts de définition et de décision

Les quatre premiers statuts décrivent la progression habituelle d’une décision :

À définir → En réflexion → À valider → Validé

Les mentions Prévu, Hors périmètre et Abandonné précisent plutôt la place d’un élément dans la trajectoire générale du projet.

Statuts documentaires

Les statuts documentaires décrivent la maturité d'une page ou d'un ensemble de chapitres. Ils ne remplacent ni les statuts de décision ni les futurs statuts de réalisation.

Statut documentaire	Signification
Rédaction initiale terminée	Le contenu prévu est présent, mais une revue ou une consolidation peut encore être nécessaire avant qu'il ne devienne la référence courante.
En consolidation	Une revue a identifié des corrections ciblées en cours d'intégration. Le contenu reste consultable, mais les points concernés ne doivent pas être considérés comme stabilisés.
Disponible	La page constitue la référence documentaire courante. Elle peut encore évoluer avec le projet sans être considérée comme définitive.
Validé	Une décision explicitement identifiée a été retenue. Ce terme qualifie une décision ou un principe, et non automatiquement l'intégralité de la page qui le contient.

Une partie peut donc être disponible comme référence courante tout en contenant des sujets prévus, indicatifs ou encore à définir. Inversement, une décision validée peut apparaître dans un chapitre dont la rédaction globale reste en consolidation.

À définir

Le sujet a été identifié, mais aucune solution suffisamment précise n’a encore été étudiée.

Ce statut permet de signaler qu’une décision sera nécessaire sans laisser entendre qu’une orientation particulière a déjà été retenue.

En réflexion

Le sujet est en cours d’étude. Plusieurs possibilités peuvent être envisagées, comparées ou expérimentées, mais aucune proposition n’est encore prête à être soumise à une validation définitive.

Les éléments présentés sous ce statut peuvent évoluer fortement.

À valider

Une proposition suffisamment précise existe et constitue l’orientation privilégiée, mais elle attend encore une confirmation formelle avant de devenir la référence du projet.

Des ajustements restent possibles avant sa validation.

Validé

La décision a été retenue et constitue la référence actuelle du Projet Horizon.

Un élément validé doit être pris en compte dans les décisions et les développements futurs tant qu’il n’est pas explicitement remplacé par une nouvelle décision. Ce statut ne signifie pas que l’élément est déjà développé, testé ou disponible.

Prévu

L’élément est retenu dans la trajectoire du projet, mais son fonctionnement détaillé, son contenu exact ou ses conditions de réalisation peuvent encore rester à définir.

Une fonctionnalité prévue n’est donc ni une simple idée ni nécessairement une décision entièrement validée. Certains de ses principes peuvent être établis tandis que ses modalités restent en réflexion.

Hors périmètre

L’élément n’est pas pris en charge dans le périmètre considéré.

Le périmètre concerné doit toujours être précisé :

• Hors périmètre d’une phase de conception.
• Hors périmètre d’un prototype.
• Hors périmètre d’une version.
• Hors périmètre de la V1.
• Hors périmètre du Projet Horizon.

Être hors périmètre d’une version ne signifie pas que l’élément est abandonné. Il peut être reporté à une étape ultérieure.

Abandonné

La proposition a été étudiée, puis explicitement écartée.

Un élément abandonné ne reste présenté dans la documentation courante que s’il permet de comprendre une décision importante ou d’éviter que la même piste soit réexaminée sans raison. Dans les autres cas, son ancienne présence reste consultable dans Git.

Les abandons ayant une influence majeure sur l’évolution d’Horizon peuvent également être mentionnés dans le chapitre consacré à l’historique des versions.

Repères temporels

Horizon doit progressivement reprendre ou remplacer plusieurs systèmes déjà employés dans La Tanière. Les repères suivants permettent de distinguer ce qui existe aujourd’hui du fonctionnement envisagé à terme.

Repère	Signification
État actuel	Fonctionnement réellement en place au moment de la rédaction.
Solution transitoire	Fonctionnement temporairement conservé pendant la conception, le développement ou la migration vers Horizon.
Fonctionnement cible	Comportement attendu lorsque l’architecture prévue d’Horizon sera mise en place.

Ces repères peuvent être associés à un statut de décision.

Exemple

Fonctionnement cible — Validé

Twitch, Discord et le poste de commande Web utilisent une identité centrale commune pour chaque membre de l’équipage.

La mention Fonctionnement cible ne signifie toutefois pas que le fonctionnement décrit est déjà disponible.

Informations indicatives

La mention Indicatif signale une information utilisée comme repère de planification ou comme hypothèse de travail, sans constituer un engagement définitif.

Elle peut notamment accompagner :

• Une date ou une période.
• Une estimation de charge.
• Une durée de développement.
• Le contenu prévisionnel d’une version.
• Un volume de données ou d’utilisateurs.
• Un exemple d’architecture ou d’implémentation.

Sauf indication contraire, les calendriers, les charges de travail et le contenu des futures versions présentés dans cette documentation doivent être considérés comme indicatifs. Ils pourront être révisés en fonction de l’apprentissage technique, des difficultés rencontrées et de l’évolution du périmètre.

Qualification des valeurs numériques

Une valeur numérique présentée dans la documentation doit être accompagnée d'un statut lorsque sa portée pourrait être ambiguë. Horizon distingue notamment :

• Une Exigence fonctionnelle, dont la valeur fait partie du comportement validé.
• Une Valeur initiale configurable, retenue pour le premier fonctionnement mais modifiable sans remettre en cause le principe fonctionnel.
• Une Hypothèse d'expérimentation, destinée à être confirmée ou corrigée par les essais.
• Une Limite de service, imposée par un fournisseur, une interface ou une capacité technique externe.
• Une Information indicative, utilisée comme ordre de grandeur sans constituer une règle.

Une valeur initiale configurable ne doit pas être présentée comme une constante définitive. Sa modification doit rester contrôlée, traçable lorsqu'elle affecte des données ou des droits, et compatible avec les garanties fonctionnelles du chapitre concerné.

Lorsqu'un seuil exact dépend encore d'essais techniques, le chapitre doit définir le principe attendu et signaler explicitement que la valeur reste à mesurer. L'absence de valeur définitive ne doit pas conduire à employer une plage ambiguë dans une règle destinée à être exécutée.

Force des formulations

Certains chapitres, notamment ceux consacrés à l’architecture, aux permissions et à la sécurité, utilisent des formulations exprimant différents niveaux de contrainte.

Formulation	Portée
Doit / ne doit pas	Règle ou contrainte obligatoire. Toute exception nécessite une décision explicite et documentée.
Devrait / ne devrait pas	Recommandation générale à respecter, sauf justification particulière.
Peut	Possibilité autorisée ou comportement facultatif.

Ces termes permettent de distinguer une exigence indispensable au fonctionnement ou à la sécurité d’Horizon d’une simple préférence de conception.

Convention éditoriale des listes

Afin de maintenir une présentation homogène dans l'ensemble de la documentation :

• Chaque élément de liste commence par une majuscule.
• Chaque élément de liste se termine par un point.
• Une liste ne doit pas employer une succession de points-virgules pour relier artificiellement des éléments indépendants.
• Une phrase introductive doit rester grammaticalement correcte lorsque les éléments de la liste sont lus séparément.

Cette convention s'applique aux listes à puces de la documentation. Les tableaux, fragments de code, chemins, identifiants techniques et composants d'interface suivent les règles propres à leur format.

Règles d’utilisation

Les conventions n’ont pas vocation à accompagner systématiquement chaque paragraphe. Elles sont affichées lorsque le niveau de définition, la période concernée ou la portée d’une information pourrait prêter à confusion.

Plusieurs conventions peuvent être combinées lorsqu’elles décrivent des dimensions différentes. Une fonctionnalité peut, par exemple, être à la fois :

• Prévue pour une future version.
• Fondée sur un principe déjà validé.
• Décrite selon son fonctionnement cible.
• Associée à une date de réalisation indicative.

Statuts de réalisation

L’absence de statut technique ne permet jamais de conclure qu’une fonctionnalité est déjà développée. Les statuts de réalisation tels que Non commencé, En développement, Implémenté, Testé ou Déployé seront ajoutés lorsque le développement d’Horizon aura débuté.

Évolution des conventions

Cette liste constitue la convention initiale de la documentation. Elle pourra être complétée à mesure que le Projet Horizon gagnera en maturité.

Toute nouvelle convention utilisée régulièrement devra être définie dans ce chapitre afin de conserver une interprétation commune dans l’ensemble de la documentation.