Cahier des charges back-office

Les outils internes échouent rarement à cause de la complexité du code. Une fonctionnalité est mentionnée une fois en réunion, personne ne consigne comment elle fonctionne réellement, et six mois plus tard le manque apparaît en production. La source du problème était dans la spécification : un sujet nommé qui n'a jamais été transformé en processus défini.

C'est pour cela que nos spécifications sont longues. Le document que nous rédigeons pour un outil back-office couvre chaque processus, chaque écran champ par champ, chaque tableau et graphique avec la formule derrière chaque chiffre, le modèle de données, la stack et les bibliothèques, et les modèles de PDF que chaque module produit. Nous détaillons tout, parce que chaque point laissé dans le vague dans une spécification revient plus tard sous forme de bug.

Lire tout d'abord

Avant d'écrire une ligne, nous lisons l'intégralité du dossier projet, pas un échantillon. Deux sources passent en premier.

Les transcriptions de visioconférences portent les vraies règles métier, les difficultés quotidiennes, et les sujets qui comptent réellement pour le client, dans ses propres mots. C'est là que vit la vérité du processus, pas dans un résumé bien ordonné.

Le brief que nous rédigeons nous-mêmes vient ensuite : notre propre cadrage du périmètre, la synthèse de ce que l'outil doit couvrir. Il devient la colonne vertébrale de la spécification. Autour de lui, nous lisons le devis, les emails, les exports et les écrans de l'outil existant, le glossaire métier, les documents de stack.

Le brief ouvre les questions

Le brief est rédigé avant la spécification, délibérément. Son rôle n'est pas de résumer : c'est de faire remonter chaque sujet que l'outil touche. Chaque mention d'un sujet ouvre un processus de définition complet pour ce sujet.

Une fonctionnalité nommée en passant devient un module entier : ses écrans, ses champs, ses statuts, ses règles. Un tableur dont l'équipe dépend encore devient un plan de migration de données. Un outil externe qui doit rester synchronisé devient une intégration : ce qui transite, dans quel sens, quel côté est la source de vérité. Nous parcourons le brief ligne par ligne et transformons chaque sujet en un emplacement nommé portant ses propres questions ouvertes.

Grill-me répond à tout

Ces questions ouvertes sont ensuite fermées par grill-me, notre méthode de questionnement : elle parcourt le plan une question à la fois, chacune accompagnée d'une réponse recommandée sur laquelle réagir, et refuse d'avancer tant qu'un point reste flou. Appliqué à une spécification, cela signifie que chaque sujet ouvert est résolu en direct sur la page. Les sujets sont abordés dans un ordre où les premiers contraignent les suivants : les rôles d'abord, puis les flux métier, les données, les vues, les tableaux et graphiques, les intégrations, la stack, le phasage. Un sujet quitte l'entretien soit entièrement défini, soit, s'il reste réellement en suspens, consigné comme risque ouvert explicite. Jamais comme une supposition vraisemblable.

Ce qu'exhaustif signifie, concrètement

Pour chaque module, la spécification définit l'ensemble :

• Les flux métier, de bout en bout et numérotés : qui fait quoi, dans quel état, avec chaque branche et chaque exception.
• Chaque vue, champ par champ : les champs d'en-tête, ceux qui sont obligatoires, les statuts, les boutons, les valeurs par défaut, la validation.
• Chaque tableau et graphique : les colonnes, les tuiles KPI, les filtres, et la formule exacte derrière chaque chiffre.
• Les statuts et la numérotation : listes de statuts fermées, règles de numérotation continue.
• Les modèles de PDF que le module produit.

Autour des modules se trouvent les couches définies une seule fois : le modèle de données, les référentiels éditables qui ne doivent pas être figés dans le code, les règles pour l'éditeur riche, les exports et les notifications, et la stack avec ses bibliothèques.

Un extrait concret

Il est facile d'affirmer qu'on est rigoureux : voici un extrait réel de l'une de nos spécifications. C'est la section 8.0, les conventions de base appliquées à chaque entité du système, rédigées une seule fois pour ne jamais avoir à les répéter table par table :

8.0  Conventions & types de base

Champs systématiques, présents sur chaque table :
  id          uuid v4        clé primaire générée serveur, immuable
  createdAt   timestamptz    horodatage de création, non éditable
  updatedAt   timestamptz    mis à jour à chaque écriture
  archivedAt  timestamptz?   archivage logique : non-null = archivé, purge auto
                             30 jours après ; toute liste filtre archivedAt IS NULL

Types métier normalisés :
  Montant     Decimal(12,2)  stocké brut, jamais une chaîne formatée
  Pourcentage Decimal(6,4)   ratios et taux (coefficient de marge, taux de TVA)
  Quantité    Decimal(12,3)  autorise les fractions (heures, mètres)
  Heures      Decimal(6,2)   durée en heures décimales
  Date        date           stockée ISO, affichée JJ/MM/AAAA
  Texte riche HTML dans text  sanitizé à l'entrée (whitelist de balises, anti-XSS),
                             rendu tel quel dans le PDF généré
  Fichier     URL signée      stockage objet privé, URLs signées à durée limitée ;
                             whitelist MIME validée par magic bytes, pas l'extension ;
                             exécutables et SVG rejetés

Chaque entité de la spécification hérite de ces règles. C'est ce que l'exhaustivité apporte : un développeur, ou un agent, n'a jamais à deviner comment un montant est stocké, comment une date s'affiche, ni ce qu'il advient d'une ligne supprimée.

Standardisé par référence, jamais réinventé

Nous construisons de la même façon à chaque fois, de sorte que la spécification n'explique jamais à nouveau une méthode que nous maîtrisons déjà. Pour tout ce qui est standardisé, elle indique ce dont ce client a besoin et renvoie à la méthode qui porte le comment : le design system et la bibliothèque de composants, la façon dont nous intégrons la facturation électronique, l'authentification et les permissions par rôle, la sécurité, le modèle de données et l'API, et le déploiement. La spécification dit quoi, la méthode référencée dit comment. C'est ce qui rend un document de 100 pages cohérent plutôt que contradictoire.

Une relecture intégrale, jusqu'à la cohérence totale

Un premier jet terminé n'est pas une spécification terminée. Nous lisons l'intégralité du document de bout en bout, et chaque observation, qu'il s'agisse d'un trou, d'une incohérence ou d'une règle entrant en collision avec autre chose que nous intégrons, rouvre l'entretien sur ce point précis et la spécification est corrigée. Nous bouclons jusqu'à ce qu'une relecture complète ne produise aucune observation. Ce n'est qu'à ce moment que la spécification est en cohérence totale avec tout ce que l'outil fera.

Ce avec quoi vous repartez

Un document à partir duquel un agent, ou un développeur, peut construire n'importe quel module sans avoir à revenir poser des questions. Chaque sujet qui a été mentionné est défini, chaque vue, tableau et formule est sur la page, la stack et les standards sont nommés. C'est la source unique que chaque agent lit avant de toucher un ticket, et la raison pour laquelle l'outil livré est l'outil dont on avait besoin.

---

Toute cette méthode tient en une skill : write-back-office-prd, qui orchestre les méthodes standardisées ci-dessus. Pour voir ce que nous construisons, nos services décrivent le travail. Et si vous avez déjà un outil interne en tête, démarrez un brief sur la page d'accueil et nous le transformons en spécification sur laquelle vous pouvez construire.