Spec Kit : coordonner une conception sur plusieurs projets

Une évolution qui traverse plusieurs applications demande une description commune du comportement attendu. Chaque projet peut ensuite préparer son implémentation, à condition de partir des mêmes décisions sur les données, les droits et les erreurs.

Spec Kit, publié par GitHub, propose un outillage de développement guidé par les spécifications : définition du besoin, plan technique et tâches d’implémentation. La méthode multi-projet présentée ici est une proposition d’organisation autour de cette séparation ; elle ne suppose pas qu’un outil coordonne automatiquement tous vos dépôts. Dépôt officiel de Spec Kit.

Écrire une décision partagée

Exemple fictif. Une date de rendez-vous peut être modifiée depuis un portail web et une application mobile. Le téléphone peut travailler hors connexion. Le serveur doit accepter une modification ou signaler qu’un changement plus récent existe déjà.

La spécification commune doit préciser qui peut modifier la date, quelle version fait autorité et quel message l’utilisateur voit en cas de conflit. Sans cette décision, chaque application peut implémenter correctement une interprétation différente.

Le choix d’une bibliothèque mobile ou d’un composant web peut rester local tant qu’il ne change pas ce comportement commun.

Séparer les artefacts utiles

Chaque plan local doit référencer la version du contrat qu’il applique. Une copie indépendante de la même règle dans trois documents rend sa maintenance plus difficile.

Faire remonter les contraintes locales

Un agent travaillant sur le mobile peut découvrir que l’application ne conserve pas la version nécessaire pour détecter un conflit. Cette observation doit revenir à la conception commune : elle peut changer le stockage, l’échange ou l’expérience attendue.

Le plan local ne doit pas contourner silencieusement la règle. La personne responsable de la décision examine la contrainte, modifie le contrat si nécessaire et indique quels projets doivent reprendre leur plan.

Les agents peuvent préparer des propositions et des revues. L’arbitrage reste attribué à une personne ou à un rôle nommé ; la présence de plusieurs réponses cohérentes ne remplace pas cette responsabilité.

Vérifier les échanges, puis le parcours

Des tests locaux vérifient le comportement d’un composant. Une recette transverse doit aussi couvrir la modification sur le web, sa consultation sur mobile et un conflit après une période hors connexion.

Il faut examiner les valeurs échangées et les états visibles. Un serveur qui renvoie une erreur correcte ne suffit pas si l’interface annonce une réussite. Inversement, un écran cohérent peut masquer une donnée qui n’a pas été enregistrée.

Rendre un échange discutable avec Mermaid

Mermaid permet de décrire un diagramme avec du texte. Un diagramme de séquence est utile pour discuter l’ordre des échanges entre une application et un serveur.

Voici un exemple fictif, sous forme de source à copier dans un éditeur compatible Mermaid :

sequenceDiagram
    participant M as Application mobile
    participant S as Serveur
    M->>S: Envoyer la modification avec la version lue
    alt Version toujours courante
        S-->>M: Modification enregistrée et nouvelle version
    else Document modifié entre-temps
        S-->>M: Conflit à résoudre, aucune écriture
    end

Cette représentation rend visible une décision : une version périmée doit-elle bloquer l’écriture ? Le diagramme aide à relire le contrat. Un test d’intégration doit ensuite vérifier que le serveur applique réellement ce comportement.

Maintenir une méthode proportionnée

Essayez cette organisation sur une évolution délimitée. Regardez si les documents aident à arbitrer et si la recette détecte des divergences utiles. Le nombre de commandes ou de fichiers produits ne constitue pas un résultat.

Pour préparer une évolution transverse, je propose de commencer par le parcours utilisateur, les composants concernés et les décisions qu’ils doivent partager. Une spécification légère peut suffire au départ ; elle s’enrichit lorsque les dépendances le nécessitent.