Ce qu'un auditeur demande quand il demande vos specs

Dans presque toutes les équipes que nous rencontrons, la revue de spec existe déjà. Elle se passe en réunion, dans un fil de commentaires, dans un tableau où quelqu'un finit par écrire « relu OK », ou dans un message privé un vendredi soir. Elle existe, elle est sérieuse, et elle ne laisse rien derrière elle.

Le jour de l'audit, la question posée n'est pas celle qu'on avait préparée. Personne ne demande si vous relisez vos specifications. On vous demande de montrer la version qui a été relue, et la trace de ceux qui l'ont approuvée. Ce sont deux questions très différentes, et la seconde se prépare des mois à l'avance ou ne se prépare pas du tout.

Ce que la clause demande réellement

La gestion de configuration logicielle, dans l'IEC 62304, ne prescrit aucun outil. Elle demande trois propriétés : identifier les éléments de configuration, maîtriser leurs modifications, et retrouver l'historique de ces modifications. L'ISO 13485, de son côté, attend d'une revue de conception qu'elle soit enregistrée, avec ses participants et ses conclusions.

Aucun de ces textes ne parle de logiciel de gestion de specs. Ce sont des propriétés à démontrer, pas des cases à cocher. Et c'est une bonne nouvelle, parce que trois d'entre elles sont déjà résolues par des outils que vos équipes techniques utilisent tous les jours.

Trois propriétés qu'un dépôt Git donne gratuitement

Si vos specs sont des fichiers texte dans un dépôt Git, vous avez déjà, sans rien faire de plus :

• l'identification : chaque fichier a un nom stable, chaque état du dépôt une empreinte unique ;
• la maîtrise des modifications : rien n'entre sans un commit, et un commit porte son auteur, sa date et son contenu exact ;
• la traçabilité : l'historique est complet, il ne se réécrit pas sans que ça se voie, et il remonte au premier jour.

Reste la quatrième, celle qu'un dépôt ne porte pas seul : la revue approuvée, rattachée à un état précis du document. Git sait qui a écrit. Il ne sait pas qui a relu, ni sur quoi.

« Porter sur un état », concrètement

L'expression est abstraite jusqu'à ce qu'on regarde ce qu'elle implique dans un outil.

Une approbation qui porte sur un document se contente de nommer un fichier : « SRS-042, approuvée par M. Roche ». Elle survit à toutes les réécritures suivantes, parce qu'elle ne dit rien du texte. C'est une approbation d'intention.

Une approbation qui porte sur un état nomme un contenu exact. Dans notre cas, la révision du nœud dans le dépôt, c'est-à-dire une empreinte. Deux conséquences immédiates, et ce sont elles qui font toute la différence au moment de l'audit :

• on peut reconstituer ce qui a été lu, au caractère près, des années plus tard ;
• on peut détecter qu'un texte a bougé depuis, sans dépendre de la mémoire de personne.

La seconde est la plus utile en pratique, et pas seulement pour l'audit. Elle transforme une question de confiance en une question de calcul. Personne n'a plus à se demander si la version relue était bien celle qui a été publiée : la réponse est dans le dossier, et elle est vérifiable par quelqu'un qui n'était pas là.

La règle qui coûte, et qu'il faut garder

C'est là que la plupart des dispositifs s'effondrent, et pas par négligence. Ils s'effondrent sur une question d'apparence anodine : que devient une approbation quand le texte change après elle ?

La réponse confortable est « elle reste, le changement était mineur ». Elle est confortable et elle est indéfendable. Personne ne pourra dire, trois ans plus tard, si la correction d'une coquille était bien une coquille. Si une approbation survit à une modification du texte, elle ne dit plus rien de ce qui a été lu.

Si le texte change après la première approbation, celle-ci tombe. C'est brutal, et c'est la seule règle qui rend une revue vérifiable.

Nous avons construit Spegit! sur cette règle, en connaissance de son prix. Une virgule ajoutée à une spec approuvée par deux personnes renvoie ces deux personnes devant leur écran. Dans les faits, ça change la façon d'écrire : on relit avant de soumettre, et on soumet moins souvent. C'est exactement l'effet recherché.

La contrepartie est que l'outil doit rendre ce nouveau tour bon marché. Voir ce qui a changé depuis l'approbation, au mot près, en approuver de nouveau en deux clics : sans ça, la règle serait juste tenue pour une punition, et quelqu'un finirait par la contourner.

« Ça va nous ralentir »

C'est l'objection qu'on entend le plus souvent, et elle mérite mieux qu'une réponse commerciale. Elle est fondée : oui, une approbation qui tombe à chaque modification ajoute des tours de relecture. La question n'est pas de le nier, c'est de savoir ce qu'on paie et ce qu'on achète.

Ce qu'on paie est visible tout de suite : des relectures en plus, surtout au début, le temps que l'équipe prenne l'habitude de soumettre un texte fini plutôt qu'un brouillon.

Ce qu'on achète est invisible jusqu'au jour où il compte. Nous avons vu des équipes passer trois jours avant un audit à reconstituer qui avait relu quoi, en fouillant des fils de messagerie et des comptes rendus de réunion. Trois jours de deux personnes, à chaque audit, pour produire une preuve approximative que l'auditeur acceptera ou non. C'est le coût réel de l'alternative, et il n'apparaît dans aucun planning.

Il y a aussi un effet qu'on n'avait pas anticipé et que les équipes nous rapportent : les specs rétrécissent. Quand une modification coûte un tour de relecture, on arrête d'écrire dans une specification ce qui n'a pas à y être. Les exigences deviennent plus courtes, plus vérifiables, et les détails d'implémentation migrent là où ils doivent vivre. Ce n'est pas ce que nous cherchions, mais c'est l'effet le plus apprécié.

Ce qu'un auditeur regarde en trente secondes

Voici la pièce que nous cherchons à rendre produisible sans y penser. Ce n'est pas un écran de notre produit, c'est ce qu'un auditeur reconstitue à la main quand il ne l'a pas :

spec SRS-042 · version figée v3
  empreinte     a91f4c2
  approbations  2 / 2
    M. Roche      2026-07-16 14:02  approuvée
    L. Ferreira   2026-07-17 09:41  approuvée
  fusion        2026-07-17 10:15  par M. Roche
  signature     2026-07-20 11:03  par A. Keller

Quatre lignes, et chacune répond à une question qu'on vous posera : sur quel état, par qui, quand, et qui en porte la responsabilité finale. Tout le reste de l'interface n'existe que pour produire ces quatre lignes sans que personne ait à les composer.

Ce que cela ne vous donne pas

Un point, pour finir, parce qu'il est trop souvent passé sous silence par les éditeurs de notre catégorie, nous compris si nous n'y faisions pas attention.

Un outil ne rend pas un dossier conforme. Il ne peut pas le rendre conforme, parce que la conformité dépend de votre taxonomie, de votre analyse de risque, de la classification de votre logiciel et du contenu réel de vos exigences. Ce que Spegit! fait, c'est rendre une revue démontrable et une version figée. La démonstration reste la vôtre, et la charge aussi.

Si vous cherchez un produit qui vous délivre une attestation, nous ne sommes pas cet outil, et nous doutons qu'il existe. Si vous cherchez à ne plus passer trois jours, avant chaque audit, à reconstituer qui avait relu quoi, c'est précisément le problème sur lequel nous travaillons.