Choisir une boucle de développement

Statut documentaire : guide — voir Maturité et preuves.

Choisir la boucle initiale en fonction du risque du projet, pas d’une préférence méthodologique.

Situation du projet	Départ recommandé	Pourquoi
Processus métier connu, cycle de livraison court	Model-first	Obtenir rapidement une application conceptuelle fonctionnelle.
Application CRUD ou workflow existante à moderniser	Model-first	Remplacer progressivement la structure d’implémentation par des concepts, actions et projections.
Ontologie qui émerge pendant la découverte produit	Model-first, puis synthèse H-Logic	Laisser l’application révéler les distinctions utiles avant consolidation.
Domaine riche en règles ou réglementé	H-Logic-first	Valider vocabulaire, contraintes et déductions avant les artefacts Runtime.
Intégration de connaissances hétérogènes	H-Logic-first	Résoudre chevauchements et contradictions avant les projections.
Acquisition de connaissances assistée par LLM	H-Logic-first	Traiter la connaissance générée comme une proposition à parser et valider.
Prototype centré UI avec sémantique simple	Model-first	Ne pas introduire de complexité logique avant qu’elle apporte de la valeur.
Aide à la décision nécessitant explications et inférences	H-Logic-first	Le modèle symbolique fait partie du contrat produit.

Changer de boucle

Un projet peut passer de model-first à H-Logic-first quand la cohérence entre modèles devient difficile à réviser. Il peut revenir vers model-first lorsque le noyau sémantique est stabilisé et que le travail principal concerne les vues, services, processus et le déploiement.

Cycle mixte utile :

texte métier -> modèles -> retours Runtime -> synthèse H-Logic -> revue de cohérence -> squelettes régénérés -> retours Runtime

La méthode ne doit pas obliger chaque développeur à comprendre les détails internes du parseur ou des algorithmes d’inférence.