# Spécifications Techniques Détaillées

| | |
| --- | --- |
| **Projet** | *à compléter* |
| **Version** | *à compléter* |
| **Date** | *à compléter* |
| **Auteur** | *à compléter* |
| **Rédigé par** | MOE / concepteur technique |
| **Destinataires** | Développeurs, testeurs techniques, mainteneurs |
| **Statut** | Brouillon / En relecture / Validé |

---

## 1. Identification et rattachement

<!-- Le lien avec le niveau fonctionnel et le suivi de version. -->

<!-- Points à couvrir :
     - Identifiant du composant, version, statut
     - SFD et exigences couvertes
     - Renvoi vers le DAT pour le cadre architectural
-->

*à compléter*

## 2. Rappel du besoin

<!-- Quelques phrases pour que le document se lise sans ouvrir les SFD en parallèle. -->

*à compléter*

## 3. Découpage technique

<!-- Les composants, modules ou classes à réaliser, et leur responsabilité. -->

<!-- Points à couvrir :
     - Schéma des composants et de leurs dépendances
     - Responsabilité de chacun, en une phrase
     - Composants réutilisés depuis l'existant, plutôt que redéveloppés
-->

*à compléter*

## 4. Modèle physique de données

<!-- Le détail des structures de stockage, au niveau du champ. -->

<!-- Points à couvrir :
     - Tables, colonnes, types, longueurs, nullabilité, valeurs par défaut
     - Clés primaires, clés étrangères, contraintes d'intégrité
     - Index, avec la requête qu'ils servent à accélérer
     - Volumétrie attendue par table à trois ans, et stratégie de purge
-->

*à compléter*

## 5. Description des traitements

<!-- L'algorithme, au niveau où un développeur n'a plus de décision de conception à prendre. -->

<!-- Points à couvrir :
     - Enchaînement des étapes, en pseudo-code ou en diagramme de séquence
     - Transactions : périmètre, points de validation, points d'annulation
     - Le traitement peut-il être relancé deux fois sans créer de doublon ni fausser un total (idempotence)
     - Parallélisme, verrouillage, gestion de la concurrence
-->

*à compléter*

## 6. Interfaces techniques

<!-- Le contrat exact des échanges, opposable aux équipes voisines. -->

<!-- Points à couvrir :
     - Signatures des services exposés : méthode, paramètres, format, codes de retour
     - Services consommés, avec leur comportement attendu en cas d'indisponibilité
     - Formats de fichiers : structure, encodage, séparateurs, nommage, dépôt
     - Contrats de message si file ou bus, avec la politique de rejeu
-->

*à compléter*

## 7. Gestion des erreurs techniques

<!-- Le comportement du composant quand son environnement se dérobe. -->

<!-- Points à couvrir :
     - Erreurs techniques prévues : indisponibilité, expiration, saturation, données illisibles
     - Politique de reprise : nombre de tentatives, temporisation, abandon
     - Journalisation : niveau, contenu, ce qui ne doit jamais être journalisé (secrets, données personnelles)
     - Remontée vers la supervision
-->

*à compléter*

## 8. Performance et dimensionnement

<!-- Les objectifs chiffrés hérités du DAT, traduits en contraintes de conception. -->

<!-- Points à couvrir :
     - Temps de traitement cible et volumétrie de référence
     - Consommation mémoire et stratégie de traitement par lots
     - Points identifiés comme sensibles, et parade retenue
-->

*à compléter*

## 9. Sécurité applicative

<!-- Les dispositions au niveau du code, pas au niveau de l'infrastructure. -->

<!-- Points à couvrir :
     - Contrôle des habilitations dans le traitement
     - Validation des entrées et protection contre les injections
     - Gestion des secrets : mode d'accès, jamais la valeur
     - Données personnelles manipulées et traitement associé
-->

*à compléter*

## 10. Tests unitaires attendus

<!-- Les cas que le développement doit couvrir, posés dès la conception. -->

<!-- Points à couvrir :
     - Cas nominaux, cas limites, cas d'erreur technique
     - Jeux de données et bouchons nécessaires
     - Couverture minimale attendue
-->

*à compléter*

## 11. Livraison et déploiement

<!-- Ce qui est produit et comment ça s'installe. -->

<!-- Points à couvrir :
     - Livrables : binaires, scripts, paramétrages, scripts de base de données
     - Paramètres de configuration, avec valeur par environnement
     - Ordre de déploiement et prérequis
     - Procédure de retour arrière du composant
-->

*à compléter*

## 12. Traçabilité

<!-- Le lien entre le niveau fonctionnel et le niveau technique. -->

<!-- Points à couvrir :
     - Tableau exigence ou SFD vers composant
     - Écarts assumés par rapport aux SFD, et justification
-->

*à compléter*

---

## Notes de rédaction

**Quand produire ce document**

- Sur un développement spécifique confié à une équipe distincte de celle qui a conçu.
- Quand la solution sera reprise en TMA ou par un autre prestataire.
- Sur les composants à forte complexité algorithmique ou à fort enjeu de performance.
- Quand une revue technique par les pairs est prévue avant le développement.

**Erreurs les plus fréquentes**

- Recopier les SFD en changeant le vocabulaire. Si les STD n'ajoutent aucune décision technique, elles ne servent qu'à alourdir la maintenance documentaire.
- Les rédiger après le développement, pour la forme. Une STD écrite après coup décrit le code au lieu de le cadrer, et n'a jamais permis d'éviter une erreur de conception.
- Ne pas dire si le traitement peut être relancé, ni comment. C'est ce qui détermine si l'exploitation pourra relancer un traitement en échec sans appeler un développeur.
- Concevoir sans volumétrie. Un traitement qui charge tout en mémoire passe la recette et tombe en production au premier vrai volume.
- Documenter les index sans dire quelle requête ils servent. Personne n'osera plus les supprimer, et ils s'accumuleront.

---

Modèle « STD - Spécifications Techniques Détaillées » (Conception technique), publié par DataALC.
Version en ligne, commentée : https://www.dataalc.com/boite-a-outils/templates/std/

Ce modèle est fourni comme base de travail : adaptez-le à votre contexte, supprimez les rubriques sans objet plutôt que de les laisser vides.