Toutes les décisions n'ont pas besoin d'être apprises. Certaines limites viennent d'un contrat, d'une politique ou d'une contrainte physique. Un système hybride réserve ces points aux règles explicites et utilise un modèle là où les signaux sont nombreux ou ambigus.
Séparer obligations et estimations
Une règle convient à une condition stable et vérifiable : plafond, rôle, territoire ou donnée obligatoire. Un modèle convient mieux à une estimation comme la pertinence, la similarité ou le risque. Les deux doivent rester identifiables dans l'architecture.
Évitez de cacher une politique dans les données d'entraînement. Si une décision doit toujours être interdite, appliquez la règle côté serveur, même lorsque le modèle propose autre chose.
Ordonner la décision
Les contrôles d'accès et de validité viennent avant le modèle. La sortie du modèle passe ensuite par des seuils et des règles de conséquence. Enfin, le système produit une action, une demande d'information ou une escalade.
Journalisez la règle et les éléments décisifs. L'explication ne doit pas révéler des secrets ni inventer une certitude, mais permettre de comprendre quel mécanisme a conduit au résultat.
Tester les interactions
Testez les règles seules, le modèle seul et la chaîne complète. Les cas limites se trouvent souvent à la frontière : donnée manquante, score proche du seuil ou règles contradictoires.
Versionnez règles, modèle et ordre d'exécution ensemble. Une modification de politique peut changer la performance apparente sans que le modèle ait bougé. Le suivi doit distinguer ces causes.
Architecture de décision
- Lister les règles obligatoires et leur propriétaire
- Réserver au modèle les estimations ambiguës
- Valider accès et entrées avant l'inférence
- Tracer règle, score et conséquence
- Tester les frontières et contradictions
L'hybridation ne réduit pas l'intelligence d'un produit. Elle place chaque décision dans le mécanisme le plus clair, contrôlable et adapté.
