Vos specs vivent dans votre dépôt, pas dans notre base

Il y a une question qu'on ne pose presque jamais pendant une démonstration, et qui décide de tout cinq ans plus tard : où vivent mes données, exactement ?

La réponse habituelle des outils de gestion d'exigences est « chez nous, et vous pouvez exporter ». C'est une réponse acceptable jusqu'au jour où vous devez vraiment partir, et où vous découvrez ce que l'export contient : une archive de fichiers bureautiques, sans historique, sans les liens entre les exigences, et sans les revues. Vous avez vos textes. Vous avez perdu leur généalogie, c'est-à-dire ce qu'un dossier réglementaire vient chercher.

Ce que « dans votre dépôt » veut dire exactement

Spegit! est posé au-dessus de votre dépôt Git, chez votre fournisseur, sur votre compte. Chaque nœud de specification y est un fichier Markdown, avec un en-tête lisible qui porte son identifiant, son type, ses parents et son statut. Un enregistrement dans notre éditeur produit un commit dans votre dépôt, signé de la personne qui a écrit.

La conséquence est simple à vérifier, et nous vous encourageons à le faire avant de nous faire confiance : clonez votre dépôt et ouvrez les fichiers. Vous n'avez pas besoin de nous pour les lire, pas besoin d'un export, pas besoin d'un format intermédiaire. Un éditeur de texte suffit, et vos outils de revue de code aussi.

C'est aussi ce qui rend le travail vérifiable dans l'autre sens : quand un auditeur demande quel était l'état d'une exigence à une date donnée, la réponse est dans votre historique, pas dans notre base.

Ce que nous conservons, limitativement

Il serait facile d'écrire « nous ne stockons rien de vos specs » et de s'arrêter là. Ce serait faux sur un point, et une promesse fausse sur un point suffit à rendre tout le reste suspect. Voici donc la liste complète, la même que celle publiée dans le produit, sur l'écran du dépôt de chaque projet :

• le lien vers le dépôt : son nom, la branche suivie, le dossier des specs ;
• l'appartenance à l'organisation : qui est membre, avec quel rôle ;
• les droits : les accès par projet, et la désignation de ceux qui peuvent publier ;
• le journal d'audit : les événements scellés, qui ne se modifient pas ;
• les préférences de compte : nom affiché, langue, notifications ;
• la trace des revues : les décisions par nœud, leurs motifs et les fils de discussion, conservés y compris après la fusion ;
• le lot en cours : votre travail non encore enregistré, et rien d'autre.

La dernière ligne est la seule exception à la promesse, et nous la nommons plutôt que de la dissimuler. Le lot est du contenu, et il vit chez nous pour une raison précise : sans lui, une session qui expire ou un onglet qui se ferme vous feraient perdre votre frappe. Il cesse d'exister de notre côté dès que vous enregistrez, parce qu'il devient un commit.

Tout le reste du contenu n'a aucune copie chez nous. Pas de cache de lecture, pas de miroir de la taxonomie, aucun document d'export conservé. Ce qui s'affiche est relu de votre dépôt à chaque consultation.

Comment le vérifier vous-même, avant de nous croire

Une promesse d'architecture se teste. Voici les trois gestes que nous suggérons à toute équipe qui évalue le produit, dans cet ordre, avant de signer quoi que ce soit.

Clonez le dépôt et lisez un fichier. Pas un export : le fichier. Vous devez y trouver le texte de votre exigence, en clair, avec un en-tête lisible portant son identifiant, son type et ses liens. Si vous avez besoin d'un outil pour comprendre ce que vous lisez, la promesse est déjà entamée.

Regardez l'historique. git log sur un nœud doit vous rendre qui a écrit quoi, quand, et le contenu exact de chaque changement. C'est cette liste qu'un auditeur vous demandera de produire, et elle ne doit pas dépendre de nous.

Modifiez un fichier depuis l'extérieur, puis rouvrez l'écran. Un commit fait à la main, ou par une autre personne depuis son éditeur, doit apparaître dans le produit. S'il n'apparaît pas, c'est qu'il existe une copie quelque part, et la promesse est fausse quoi qu'on vous en dise.

Ce troisième geste est celui que nous recommandons le plus, parce que c'est le seul qui distingue vraiment un produit posé sur votre dépôt d'un produit qui l'utilise comme lieu de sauvegarde.

Le prix de ce choix, puisqu'il y en a un

Deux conséquences, et nous préférons les écrire que les laisser découvrir.

Sans accès au dépôt, il n'y a plus rien. Si le jeton d'accès est révoqué, si le dépôt est supprimé, si votre fournisseur est indisponible, le projet devient illisible chez nous aussi. Nous n'avons pas de réserve locale à vous proposer, et nous ne prétendons pas en avoir : le produit l'énonce à l'écran au lieu de laisser espérer un repli qui n'existe pas.

La revue ne passe pas par les demandes de fusion de votre fournisseur. Elle vit chez nous, en surcouche, pour une raison réglementaire : une demande de fusion approuve un ensemble de fichiers, alors que l'approbation dont vous avez besoin porte sur un nœud précis, à une révision précise, avec un motif. Nous ne touchons votre fournisseur que pour lire un diff et exécuter la fusion.

Ce que ça change pour la revue, au quotidien

Un point pratique, parce qu'il surprend souvent : puisque les specs sont des fichiers texte dans un dépôt, elles se comparent comme du code. Un changement d'exigence s'affiche ligne par ligne, et pour les modifications fines, mot par mot.

C'est un détail d'outillage qui a une conséquence réglementaire. Le relecteur qui approuve voit exactement ce qui a changé depuis l'état précédent, au lieu de relire un document entier en cherchant ce qui a bougé. Une relecture qui coûte moins est une relecture qui a lieu, et une approbation posée sur un changement compris vaut mieux qu'une approbation posée sur un document survolé.

C'est aussi la raison pour laquelle nous tenons à ce que le contenu soit du texte, et pas un format binaire. Un traitement de texte ne se compare pas ; il produit un fichier qu'un outil doit interpréter pour deviner ce qui a changé, et ce qu'il en devine n'est pas opposable.

Pourquoi ce n'est pas qu'un argument commercial

La réversibilité est une exigence des systèmes qualité, et elle est régulièrement traitée comme une formalité de contrat. Dans les faits, elle se joue le jour où une équipe change d'outil, avec un dossier technique en cours et un audit dans six semaines.

Notre position est qu'un éditeur ne devrait pas avoir besoin d'une clause de contrat pour rendre vos données. Il devrait suffire qu'elles n'aient jamais quitté votre dépôt. C'est moins spectaculaire qu'un bouton d'export, et beaucoup plus difficile à défaire.