Générateur de TSD
Écrivez l’exigence fonctionnelle une fois. Obtenez un squelette complet et bien structuré de dossier de conception technique en Markdown — vos mots conservés tels quels, avec un guidage précis dans chaque autre section.
Les dossiers écrits à la main divergent : structure différente, profondeur différente, et parfois la section qui aurait évité un incident en production est simplement absente. Cet outil fixe la structure. Votre exigence entre mot pour mot ; chaque section non remplie porte une note indiquant exactement ce qui doit y figurer. Collez le fichier dans votre dépôt et rédigez-le dans votre éditeur — un assistant comme GitHub Copilot peut rédiger à partir de ces notes, et elles se lisent tout aussi bien si vous n’en utilisez aucun.
Le raisonnement derrière cet outil est développé dans une étude : Utiliser l’IA comme moteur de cohérence pour le travail d’architecture. Vous préférez les fichiers bruts ? Les modèles sont sur GitHub — forkez-les et faites-en le standard de votre équipe.
Tout reste dans votre navigateur. Les entrées sont enregistrées localement, un rafraîchissement ne perd rien ; aucune donnée n’est envoyée nulle part.
Un nom court pour le changement, tel qu’il apparaîtrait dans un backlog.
La seule entrée qui compte. Écrivez l’exigence avec tout le détail dont vous disposez — ce que fait la fonctionnalité, pour qui, et les règles déjà connues. Elle entre dans le document mot pour mot ; les commentaires de guidage font le reste.
Options
Tout est facultatif. Les valeurs par défaut produisent un squelette complet.
Seulement si le projet utilise une plateforme en couches — par exemple : Socle, Marque, Marché, Site. Laissez vide pour omettre la section des couches impactées.
Répète le tableau d’intégration autant de fois.
Squelette généré
25 sections · 0 remplies depuis vos entrées · 25 avec le guidage
Ensuite : enregistrez ce fichier dans votre dépôt, ouvrez-le dans votre éditeur, et laissez votre assistant IA développer chaque section à partir de son guidage. La version prompt est pour ceux qui préfèrent un assistant conversationnel.
Vous voulez en faire un standard d’équipe ? Les modèles sont sur GitHub
Un assistant remplira ces sections avec un texte assuré et parfois faux. Relisez chaque section qu’il écrit : la structure est automatisée, le jugement ne l’est pas.
# Dossier de conception technique — Fonctionnalité sans titre | Champ | Valeur | | --- | --- | | Auteur | | | Ticket associé | | | Version | | ## Approbations > **Ce qu’il faut écrire ici.** Liste qui doit approuver cette conception. Garde des rôles génériques — par exemple « Architecte référent » ou « Responsable plateforme ». | Rôle | Nom | Statut | | --- | --- | --- | | Architecte référent | | En attente | ## Journal des versions | Version | Date | Auteur | Changement | | --- | --- | --- | --- | | 1 | 2026-08-13 | | Premier brouillon | ## Exigence fonctionnelle > **Ce qu’il faut écrire ici.** Colle ici l’exigence concernant cette fonctionnalité, dans les termes où elle t’a été donnée. Tout ce qui suit en découle : plus elle est détaillée, meilleur sera le reste du document. ## Objectif > **Ce qu’il faut écrire ici.** À partir de l’exigence fonctionnelle ci-dessus, décris l’objectif de cette fonctionnalité : ce que cela fait, pour qui, et pourquoi maintenant. Utilise des mots qu’un product owner validerait. ## Périmètre > **Ce qu’il faut écrire ici.** À partir de l’exigence fonctionnelle ci-dessus, indique quelles parties du système changent pour cette fonctionnalité — et, tout aussi important, lesquelles ne changent pas. Nomme ce qui est explicitement hors périmètre. ## Conception générale > **Ce qu’il faut écrire ici.** Décris la forme de la solution pour cette fonctionnalité en mots simples : les parties principales, leurs interactions, et où sont les frontières. Pas de code. ## Impact multi-sites et multi-marques > **Ce qu’il faut écrire ici.** Indique si cette fonctionnalité concerne un site ou plusieurs. Le changement est-il partagé ou surchargé par site ? Un correctif futur atteindra-t-il tous les sites automatiquement, ou devra-t-il être appliqué N fois ? ## Options envisagées et rejetées > **Ce qu’il faut écrire ici.** Liste au moins une conception alternative pour cette fonctionnalité et la raison pour laquelle elle n’a pas été retenue. Une conception sans option rejetée signifie souvent que la réflexion n’a pas eu lieu. ## Changements côté boutique > **Ce qu’il faut écrire ici.** Liste les points de contact client que cette fonctionnalité modifie : quelles pages ou parcours (fiche produit, liste, panier, paiement, compte) et ce qui change sur chacun. ## Changements côté serveur > **Ce qu’il faut écrire ici.** Décris le travail côté serveur pour cette fonctionnalité : tâches planifiées, appels de service, logique métier. Nomme tout ce qui s’exécute pendant qu’un client attend — c’est le chemin critique. ## Fichiers modifiés > **Ce qu’il faut écrire ici.** Liste chaque fichier touché par cette fonctionnalité, une ligne par fichier. Le statut est NEW, UPDATE ou RE-USE. Indiquer RE-USE compte : cela montre que le code existant a été vérifié avant d’en écrire du nouveau. | Statut | Fichier | Ce qui change | | --- | --- | --- | | NEW | chemin/vers/fichier.js | Ce qui est ajouté, sans blocs de code | ## Dépendances > **Ce qu’il faut écrire ici.** Liste les fonctionnalités, équipes, bibliothèques ou versions dont cette fonctionnalité dépend — et tout ce qui dépend de lui. ## Interfaces et intégrations > **Ce qu’il faut écrire ici.** Pour chaque intégration de cette fonctionnalité, complète le tableau : les huit lignes. Les trois dernières — délai maximal, comportement en cas de panne et authentification — sont celles qui évitent les pannes. Ajoute une description du diagramme d’interaction avec le navigateur, la plateforme et le système externe comme acteurs. ### Intégration 1 | Champ | Détails | | --- | --- | | Description | | | Protocole de communication | | | Format de données | | | Exemple de requête | | | Exemple de réponse | | | Délai maximal | | | Comportement en cas de panne | | | Méthode d’authentification | | ## Données > **Ce qu’il faut écrire ici.** Décris les données que cette fonctionnalité crée, lit ou modifie. Quel système en est la source de vérité, et quelque chose est-il partagé entre les sites ? ## Gestion des erreurs et repli > **Ce qu’il faut écrire ici.** Liste les scénarios de panne pour cette fonctionnalité — service indisponible, données invalides, délai dépassé — et le comportement attendu pour chacun : ce que voit le client, et ce que fait le système. ## Cache > **Ce qu’il faut écrire ici.** Décris la stratégie de cache pour cette fonctionnalité. Indique ce qui est mis en cache, pour combien de temps, et ce qui ne doit jamais l’être parce que c’est personnalisé. ## Impact sur la performance > **Ce qu’il faut écrire ici.** Indique le coût de cette fonctionnalité en performance : appels supplémentaires par page, durée des tâches, quotas. Dimensionne pour la pointe de trafic, pas pour un jour calme. ## Sécurité > **Ce qu’il faut écrire ici.** Indique les considérations de sécurité pour cette fonctionnalité : les secrets et où ils vivent, le chiffrement, ce qui ne doit jamais apparaître dans les journaux, et qui peut appeler les nouveaux points d’accès. ## Vie privée et protection des données > **Ce qu’il faut écrire ici.** Indique quelles données personnelles cette fonctionnalité touche, la base légale, les consentements nécessaires, la durée de conservation, et comment une demande d’accès ou de suppression serait traitée. ## Accessibilité > **Ce qu’il faut écrire ici.** Indique ce que cette fonctionnalité change pour l’accessibilité : clavier, focus, contraste, annonces. Quels composants tiers sont impliqués, un composant partagé porte-t-il le correctif à tous les sites, et qui en est responsable ? L’accessibilité se décide ici, dans l’architecture — bien avant tout outil d’audit — et dans l’UE c’est une obligation légale. ## Observabilité > **Ce qu’il faut écrire ici.** Indique ce que cette fonctionnalité journalise, ce qui est surveillé, et quelles alertes existent. Comment détecterait-on une panne de cette fonctionnalité en production avant qu’un client ne la signale ? ## Stratégie de déploiement > **Ce qu’il faut écrire ici.** Indique comment cette fonctionnalité arrive en production : avec ou sans interrupteur de fonctionnalité, progressivement ou en une fois — et pour un parc multi-sites, l’ordre dans lequel les sites et marchés la reçoivent, et pourquoi cet ordre. ## Plan de retour arrière > **Ce qu’il faut écrire ici.** Indique ce qui se passe si cette fonctionnalité échoue après la mise en production. Peut-on le désactiver sans déploiement ? Le retour arrière est-il encore sûr une fois de vraies données écrites ? ## Comment tester > **Ce qu’il faut écrire ici.** Écris des étapes façon tutoriel pour tester cette fonctionnalité, en positif et en négatif : préparation requise, test des appels de service, et les cas d’échec — données invalides, jetons vides, absence de réponse, accès refusé. ## Critères de réussite > **Ce qu’il faut écrire ici.** Indique comment vous saurez que cette fonctionnalité a fonctionné, au-delà de « c’est livré » : un chiffre, un comportement, ou une plainte qui disparaît. ## Risques et hypothèses > **Ce qu’il faut écrire ici.** Différent des questions ouvertes : liste ce que cette fonctionnalité suppose vrai, et ce qui ferait mal si ce ne l’est pas. Nomme l’hypothèse que personne n’a vérifiée. ## Questions ouvertes > **Ce qu’il faut écrire ici.** Liste les questions sur cette fonctionnalité encore sans réponse : qui doit répondre, et sur quelle exigence. --- **Chaque section développée par un assistant doit être relue par l’auteur. Il produira un texte assuré et parfois faux. La structure est automatisée ; le jugement ne l’est pas.** _Généré avec les outils de squelette documentaire de commerceatscale.com. Rien n’a été envoyé à un serveur ; tout le contenu est resté dans le navigateur._