Agissez en tant que : Architecte principal en flux de travail et modélisation de données.

Pourquoi cette tâche est importante : Un modèle de données propre et normalisé est la colonne vertébrale de toute application basée sur des formulaires. Il évite les duplications, facilite les rapports et soutient des API et automatisations stables.

Limites importantes :
- Privilégiez la normalisation de type 3NF sauf dénormalisation explicite justifiée pour la performance en lecture.
- Utilisez des noms clairs et adaptés au métier ; incluez des identifiants sûrs pour les machines.
- Rendre explicites les hypothèses et lister les questions ouvertes.

Entrées utilisateur (collez sous cette ligne) :
[Objectif métier]
[Champs principaux du formulaire]
[Parties prenantes clés]
[Exemples de besoins en aval : validations, rapports, tableaux de bord]
[Volumes et prévisions de croissance]

Objectifs :
1) Convertir le formulaire en entités, champs, types de données et contraintes.
2) Cartographier les relations (1–1, 1–plusieurs, plusieurs–plusieurs) et tables de jonction.
3) Proposer des identifiants, clés d’unicité et champs d’audit (created_at, updated_at, created_by).
4) Fournir des exemples d’enregistrements pour valider la structure et la nomenclature.

Processus d’analyse :
1) Analyser les champs du formulaire et les regrouper par entité conceptuelle.
2) Identifier les opportunités de normalisation et éliminer les groupes répétés.
3) Définir les types de champs, plages de validation et énumérations.
4) Spécifier clés primaires, clés naturelles et clés étrangères.
5) Documenter la cardinalité des relations et les comportements de suppression/mise à jour.
6) Ajouter audit, champs de statut et suppression douce si nécessaire.
7) Lister les champs dérivés et où les calculer.
8) Mettre en avant hypothèses et questions non résolues pour les parties prenantes.

Format de sortie requis :
- Liste d’entités avec : nom, description, champs[{nom, id, type, obligatoire, défaut, enum, validation}], clés, relations[{vers, type, fk, comportement}], et notes.
- Exemple JSON de 2–3 enregistrements par entité principale.
- Questions ouvertes et décisions recommandées.

Contrôles qualité :
- Nommage cohérent et singulier pour les entités, snake_case ou camelCase pour les identifiants techniques.
- Pas de champs dupliqués entre entités sans justification.
- Toutes les relations ont une propriété claire et un comportement de suppression défini.

Checklist de vérification :
- Ce modèle peut-il répondre aux 5 principales questions de reporting ?
- Les champs de statut et horodatages sont-ils présents là où le cycle de vie est important ?
- Toutes les énumérations sont-elles fermées et documentées ?

Instruction finale : Produisez d’abord le modèle et les exemples. Puis fournissez un paragraphe de justification et une courte note de migration pour les données existantes dans les feuilles de calcul.