Définir la décision avant le modèle
La première question est le problème à résoudre, pas l’algorithme à utiliser. Décrire la décision, l’utilisateur et le coût d’une erreur. Une règle simple, un meilleur reporting ou un changement de processus peut répondre au besoin. L’intérêt d’un modèle doit être évalué face à ces alternatives, sur un périmètre défini.
Décrire les sources et le droit d’usage
Inventorier les données réellement accessibles, les personnes responsables et les conditions d’utilisation. Ne pas supposer que toutes les données d’un système peuvent être réutilisées pour un autre objectif. Identifier les informations sensibles et les traitements à faire examiner par les responsables concernés. Les projets évoqués ici portent sur les opérations métier, sans conseil clinique.
Examiner l’historique disponible
Repérer les changements de catalogue, les interruptions de flux, les promotions et les événements qui modifient la lecture des ventes. Des ventes nulles peuvent traduire une absence de demande ou une absence de disponibilité. Si ces situations ne sont pas distinguées, l’interprétation d’un historique devient fragile. Documenter les informations manquantes avant de conclure à la faisabilité.
Préparer une évaluation comparable
Définir une période de test et un point de comparaison. Pour un usage temporel, les informations futures ne doivent pas servir à simuler une décision passée. Les responsables métier et techniques choisissent les critères adaptés : utilité opérationnelle, erreurs, stabilité et possibilité d’explication. Une précision annoncée sans protocole et sans périmètre ne suffit pas.
Garder une possibilité de contrôle
Préciser qui examine les sorties du modèle et comment une recommandation peut être contestée. Définir les conditions de suspension ou de retour à une règle simple. Les exceptions et les effets d’une donnée absente doivent être compris par les utilisateurs. L’outil ne doit pas transformer une incertitude en décision automatique non maîtrisée.
Cadrer un pilote limité
Un premier pilote peut produire une note de faisabilité, un jeu de données documenté, un prototype et un bilan d’évaluation. Le choix dépend des données accessibles et du risque de l’usage. Une amélioration réelle reste à démontrer : ni un résultat chiffré, ni une performance de production ne sont promis avant cette évaluation.