Pourquoi celui-là et pas un autre
Tracer ses choix techniques
Documenter les arbitrages techniques au moment où ils sont faits, pour ne pas refaire le même débat deux fois et permettre à quelqu'un d'autre de comprendre vos choix.
Une équipe qui choisit un composant, une architecture ou une méthode sans noter pourquoi s’expose à deux problèmes : le même débat peut ressurgir plus tard (“pourquoi on n’a pas pris l’autre capteur, déjà ?”), et personne d’extérieur à la décision — un nouveau membre, un encadrant, une prochaine promo — ne peut comprendre la logique du projet en le lisant.
C’est le moment annoncé dans Définir son besoin : le diagramme FAST part d’une fonction du cahier des charges et explore les solutions techniques possibles pour la remplir.
graph LR
A[FP1 : trier les déchets] --> B[Détecter le type<br/>de déchet]
B --> C1[Capteur de couleur]
B --> C2[Vision par caméra]
B --> C3[Tri par poids]
C1 --> D[Solution retenue]
Ce n’est pas un exercice théorique : c’est directement la suite de la pré-étude de faisabilité vue dans Rechercher l’existant — le test rapide du capteur de couleur, dans cet exemple, a nourri ce choix.
Pas besoin d’un document complexe. Pour chaque choix qui compte, quatre questions suffisent :
## Choix : capteur de couleur plutôt que vision par caméra
**Contexte** : le robot doit distinguer 3 catégories de déchets sous
l'éclairage réel du Forum des Sciences.
**Options envisagées** : capteur de couleur (TCS3200), vision par caméra
avec reconnaissance d'image, tri par poids.
**Choix retenu et pourquoi** : capteur de couleur — la pré-étude a montré
une précision suffisante sous l'éclairage réel, pour un coût et une
complexité bien inférieurs à la vision par caméra.
**Compromis acceptés** : moins précis qu'une caméra sur des déchets très
sales ou décolorés — acceptable pour une démonstration, à revoir si le
projet est repris pour un usage réel.
Réservez ce format aux décisions coûteuses à revenir en arrière (choix d’un composant central, d’une architecture, d’une méthode de fabrication) — pas à chaque micro-décision du quotidien, qui a déjà sa place dans le journal de bord.
Ce fichier tient dans docs/etudes.md du repo template, à la suite du
tableau comparatif de la recherche de l’existant — les deux se complètent :
l’un compare des solutions externes, l’autre documente le choix final et
pourquoi.
Sur votre projet, en équipe :