Des données aux décisions : problème, faisabilité et features

Un projet d'analytique prédictive ne tombe jamais tout fait sur le bureau du praticien. Il naît d'un problème métier — gagner de l'argent, conquérir des clients, vendre davantage, réduire les pertes liées à la fraude — et c'est au praticien de décider comment y répondre avec les techniques de l'apprentissage automatique. Or il faut le dire d'emblée : les modèles que nous construisons ne résolvent aucun de ces problèmes. Ils se contentent de faire des prédictions à partir de régularités extraites de données historiques. Ces prédictions ne résolvent rien par elles-mêmes ; elles fournissent des éclairages (insights) qui aident l'organisation à prendre de meilleures décisions. Ce chapitre déroule la première moitié du cycle CRISP-DM — comprendre le métier, comprendre les données, préparer les données — en s'appuyant d'un bout à l'autre sur une étude de cas fil rouge : la détection de la fraude à l'assurance automobile (motor insurance fraud).

Convertir un problème métier en solution analytique

La conversion d'un problème métier en solution analytique (analytics solution) est la tâche la plus importante de la phase de compréhension du métier (Business Understanding) de CRISP-DM. Elle revient, pour l'essentiel, à répondre à trois questions.

D'abord, quel est le problème métier et quels sont les objectifs visés ? Cette question n'est pas toujours simple. Certaines organisations lancent un projet parce qu'elles ont un enjeu clair à traiter ; d'autres parce que quelqu'un a entendu dire que l'analytique était une technique qu'il « faudrait » employer. À défaut d'objectifs clairement énoncés, le projet a peu de chances d'aboutir. À ce stade, le problème et les objectifs doivent être formulés en termes métier, sans se soucier encore du travail analytique proprement dit.

Ensuite, comment l'entreprise fonctionne-t-elle aujourd'hui ? Le praticien n'apprendra jamais tout d'un secteur, car il passe vite d'un domaine à l'autre, voire d'une industrie à l'autre. Il doit en revanche posséder une aisance situationnelle (situational fluency) : comprendre assez le métier pour dialoguer avec ses interlocuteurs dans leurs propres termes. Dans l'assurance, par exemple, on ne parle pas de « clients » mais de membres (members) ; du point de vue analytique la différence est mince, mais employer le bon vocabulaire facilite grandement l'engagement des partenaires métier.

Enfin, en quoi un modèle prédictif pourrait-il aider ? Pour un même problème, plusieurs solutions sont concevables. Il faut les explorer et, avec le métier, s'accorder sur la plus adaptée. Pour chaque solution candidate, on décrit trois points : (1) le modèle prédictif à construire ; (2) la manière dont le métier l'utilisera ; (3) en quoi cet usage aidera à résoudre le problème initial.

Étude de cas : la fraude à l'assurance automobile

Voici le problème. Malgré une équipe d'enquête qui examine jusqu'à 30 % de toutes les déclarations de sinistre (claims), une compagnie d'assurance automobile perd encore trop d'argent à cause des déclarations frauduleuses. Quatre solutions analytiques peuvent être proposées, qui se distinguent surtout par leur sujet de prédiction (prediction subject) — l'objet sur lequel porte la prédiction.

Solution	Modèle prédictif	Usage métier	Bénéfice attendu
Prédiction du sinistre (claim)	Probabilité qu'une déclaration soit frauduleuse	Affecter un score à chaque nouveau sinistre, signaler les plus suspects aux enquêteurs	Cibler le temps d'enquête limité sur les sinistres les plus probablement frauduleux
Prédiction du membre (member)	Propension d'un membre à frauder bientôt	Tourner chaque trimestre ; contacter ou résilier les membres à risque	Agir avant que la fraude ne survienne
Prédiction de la demande (application)	Probabilité qu'une police souscrite débouche sur une fraude	Tourner à chaque nouvelle demande ; rejeter les plus risquées	Empêcher l'entrée de futurs fraudeurs
Prédiction du paiement (payment)	Montant qui sera réellement versé après enquête	Proposer ce montant en règlement amiable	Économiser le coût d'enquête et limiter les sur-paiements

Ces quatre pistes répondent au même problème mais font des paris différents : elles n'ont pas le même sujet de prédiction (un sinistre, un membre, une demande), n'utilisent pas les mêmes données et ne s'insèrent pas au même endroit dans les processus de l'entreprise.

Évaluer la faisabilité

Une fois les solutions candidates définies, il faut évaluer la faisabilité (feasibility) de chacune. Deux questions structurent cette évaluation : les données requises sont-elles disponibles, ou peut-on les rendre disponibles ? Et quelle est la capacité de l'entreprise à exploiter les éclairages que la solution produira ?

La première question porte sur la disponibilité des données (data availability). Chaque solution a ses besoins propres, et il est utile de vérifier au plus tôt que l'entreprise dispose de quoi les satisfaire. Parfois, l'absence de données pertinentes élimine purement et simplement une piste ; plus souvent, la facilité d'accès aux données fait pencher la balance vers telle solution plutôt que telle autre. Cinq dimensions sont à confronter aux besoins de la solution.

Dimension	Question à se poser	Exemple
Objets clés	Quels sont les objets du modèle de données et que sait-on d'eux ?	En assurance : polices, sinistres, demandes, enquêtes, courtiers, membres, paiements
Connexions	Peut-on relier ces objets entre eux ?	Relier une demande de police à la police puis à ses sinistres
Granularité	À quel niveau de détail les données sont-elles stockées ?	Ventes agrégées par jour et par produit, plutôt que ligne par ligne
Volume	Combien de données dispose-t-on ?	Trop = défi technique ; trop peu = impossible d'évaluer le modèle
Horizon temporel	La période couverte est-elle suffisante ?	Connaître le solde d'un compte aujourd'hui mais pas celui d'hier

La seconde question est celle de la capacité d'exploitation. Si tirer parti d'un modèle exigeait de bouleverser tous les processus de l'entreprise, celle-ci n'y est peut-être pas prête, aussi bon le modèle soit-il. Les meilleures solutions sont souvent celles qui s'insèrent naturellement dans un processus existant.

Appliquée au cas de la fraude, l'analyse révèle des contraintes contrastées. La prédiction du sinistre suppose un large historique de déclarations étiquetées « frauduleuses » ou « non frauduleuses », avec les détails du sinistre, de la police et du déclarant ; côté capacité, l'équipe d'enquête existant déjà, il suffit de l'informer des priorités à temps. La prédiction du membre est plus lourde : elle exige de relier chaque sinistre à un membre identifiable et d'historiser tout changement de police ; surtout, contacter un membre soupçonné sans abîmer la relation client — voire sans enfreindre la loi — est délicat. La prédiction de la demande nécessiterait un historique remontant sur des décennies (le délai entre souscription et sinistre est long). Pour la suite, on retient la prédiction du sinistre : construire un modèle qui estime la probabilité qu'une déclaration soit frauduleuse.

Concevoir l'Analytics Base Table

Une fois la solution choisie, on conçoit les structures de données qui serviront à construire, évaluer puis déployer le modèle. Ce travail relève surtout de la phase de compréhension des données (Data Understanding), tout en débordant sur la compréhension du métier et la préparation des données — CRISP-DM n'étant pas strictement linéaire.

Les besoins fondamentaux sont étonnamment simples. Pour construire un modèle prédictif, il faut un grand jeu d'exemples historiques du scénario que l'on veut prédire ; chaque exemple doit décrire à la fois le scénario et le résultat (outcome) qui nous intéresse. Pour la fraude, il faut donc un grand jeu de sinistres passés dont on sait, pour chacun, s'il s'est révélé frauduleux.

La structure qui capture cet historique est l'Analytics Base Table (ABT) : une table plate, simple, faite de lignes et de colonnes. Les colonnes se divisent en un ensemble de descripteurs (descriptive features) et une cible unique (target feature). Chaque ligne représente une instance sur laquelle une prédiction peut être faite.

              <-------- descripteurs --------->   cible
         +------+------+------+-- ... --+------+----------+
inst. 1  |  d1  |  d2  |  d3  |   ...   |  dm  |    t1    |
inst. 2  |  d1  |  d2  |  d3  |   ...   |  dm  |    t2    |
inst. 3  |  d1  |  d2  |  d3  |   ...   |  dm  |    t3    |
  ...    |  ..  |  ..  |  ..  |   ...   |  ..  |    ..    |
inst. n  |  d1  |  d2  |  d3  |   ...   |  dm  |    tn    |
         +------+------+------+-- ... --+------+----------+

           une ligne = une instance du sujet de prédiction

Mais les données d'une organisation ne dorment presque jamais dans une jolie table prête à l'emploi. L'ABT doit être assemblée à partir de sources brutes très diverses — bases opérationnelles, journaux, fichiers externes. Avant d'agréger quoi que ce soit, un travail considérable de conception s'impose.

Sujet de prédiction et concepts de domaine

La première décision concerne le sujet de prédiction : le niveau auquel les prédictions sont faites. Chaque ligne de l'ABT représente une instance de ce sujet — on parle de structure une-ligne-par-sujet (one-row-per-subject). Dans le cas de la fraude, le sujet est un sinistre pour les modèles « sinistre » et « paiement », un membre pour le modèle « membre », une demande pour le modèle « demande ».

Définir directement les colonnes peut sembler titanesque. On allège la tâche en introduisant un niveau intermédiaire entre la solution et les descripteurs concrets : les concepts de domaine (domain concepts). Un concept de domaine est une abstraction de haut niveau décrivant une caractéristique du sujet de prédiction, dont on dérivera ensuite des descripteurs concrets. En collaboration avec les experts métier, on bâtit une hiérarchie qui part de la solution analytique, traverse quelques niveaux d'abstraction et débouche sur les features. À ce stade, on ne se demande pas encore comment implémenter chaque concept ; on énumère les zones d'où les descripteurs vont émerger. C'est un travail d'élicitation de connaissance (knowledge elicitation), mené sur plusieurs réunions.

Certains concepts reviennent souvent : détails du sujet, données démographiques (âge, sexe, profession), usage (fréquence, récence, valeur monétaire des interactions), changements d'usage, usage spécial (a-t-on appelé le service réclamations le mois dernier ?), phase du cycle de vie (client nouveau, fidèle, en train de partir), et liens réseau (liens entre clients ou produits).

Solution analytique : prédire la fraude sur un sinistre
   |
   +-- Détails de la police        (âge de la police, type)
   +-- Détails du sinistre         (type d'incident, montant)
   +-- Historique du déclarant
   |     +-- Types de sinistres    (variété des sinistres passés)
   |     +-- Fréquence des sinistres
   +-- Liens du déclarant
   |     +-- Liens avec d'autres sinistres
   |     +-- Liens avec le sinistre courant
   +-- Démographie du déclarant     (âge, sexe, profession)
   +-- Résultat de fraude           (la CIBLE)

Notons que le concept Résultat de fraude est inclus dès cette étape, alors qu'il décrit la cible. C'est important : les cibles doivent souvent être dérivées de plusieurs sources brutes, et l'effort que cela représente ne doit pas être oublié.

Concevoir et implémenter les features

Une feature est toute mesure dérivée d'un concept de domaine, directement incluse dans l'ABT pour être consommée par un algorithme. Leur implémentation est un travail d'approximation : on cherche à exprimer le plus possible de chaque concept à partir des sources disponibles. Souvent plusieurs features sont nécessaires pour un seul concept ; parfois on recourt à un proxy (feature de substitution) lorsque la mesure directe est impossible ; dans les cas extrêmes, on abandonne un concept faute de données.

Trois considérations dominent cette phase. La disponibilité d'abord : sans donnée historique sur six mois, pas de feature « solde moyen sur six mois ». Le moment où la donnée devient disponible ensuite : sauf pour la cible, toute donnée utilisée doit exister avant l'événement à prédire — l'affluence finale d'un match de football, connue à la mi-temps, ne peut servir à une prédiction d'avant-coup d'envoi. La longévité enfin : une feature peut rancir (go stale) si son environnement change. Un salaire utilisé sur dix ans dérive avec l'inflation ; un ratio salaire / montant du prêt durera bien plus longtemps que ces deux valeurs prises isolément. Conception et exploration des données avancent donc de manière itérative.

Les types de données

Les valeurs contenues dans l'ABT peuvent être de plusieurs types, qui conditionnent le fonctionnement des algorithmes (chapitres 4 à 7).

Type	Opérations permises	Exemple
Numérique (numeric)	Toute l'arithmétique	prix, âge
Intervalle (interval)	Ordre et soustraction, pas le reste	date, heure
Ordinal (ordinal)	Ordre seulement	taille : petit < moyen < grand
Catégoriel (categorical)	Ni ordre ni arithmétique	pays, type de produit
Binaire (binary)	Deux valeurs	sexe
Textuel (textual)	Texte libre court	nom, adresse

On réduit souvent cette typologie à deux familles : continu (numérique et intervalle) et catégoriel (catégoriel, ordinal, binaire, textuel). Pour une feature catégorielle, l'ensemble des valeurs possibles s'appelle ses niveaux (levels) ou son domaine : la feature NOTE DE CREDIT a pour niveaux {aa, a, b, c}, la feature SEXE a pour niveaux {homme, femme}.

Features brutes et features dérivées

Une feature brute (raw feature) provient directement d'une source : l'âge du client, le type de sinistre se transfèrent tels quels. Une feature dérivée (derived feature) n'existe dans aucune source brute et doit être construite à partir d'une ou plusieurs d'entre elles. La variété en est illimitée : d'un seul relevé — le paiement mensuel d'une facture d'électricité — on dérive le paiement moyen / maximum / minimum sur six puis trois mois, un drapeau « paiement manqué », un mapping vers bas/moyen/haut, le ratio entre facture courante et précédente, et bien d'autres.

Type dérivé	Définition	Exemple en assurance
Agrégats (aggregates)	count, sum, average, min, max sur un groupe ou une période	nombre total de sinistres sur la vie du membre
Drapeaux (flags)	binaire signalant la présence/absence d'une caractéristique	un sinistre a-t-il déjà été refusé ?
Ratios (ratios)	relation continue entre deux valeurs brutes	montant du sinistre / primes versées à ce jour
Mappings (mappings)	conversion d'un continu en catégoriel pour réduire le nombre de valeurs	salaire → bas / moyen / haut

La cible, elle aussi, doit fréquemment être dérivée, et sa définition demande un effort réel. Pour prédire le défaut sur un prêt, faut-il compter un défaut dès le premier paiement manqué, ou seulement après trois consécutifs ? Trois sur six mois ? Deux sur cinq ? Comme tout descripteur, la cible repose sur un concept de domaine, et il faut déterminer l'implémentation utile, faisable et correcte au regard du métier — d'où l'importance, ici plus qu'ailleurs, de l'avis des experts.

Gérer le temps : périodes d'observation et de résultat

Beaucoup de modèles sont des modèles de propension (propensity models) : ils prédisent la probabilité d'un résultat futur à partir de descripteurs décrivant le passé. Ces modèles ont une nature temporelle intrinsèque, articulée autour de deux périodes : la période d'observation (observation period), sur laquelle on calcule les descripteurs, et la période de résultat (outcome period), sur laquelle on calcule la cible.

Tantôt ces périodes sont mesurées aux mêmes dates pour tous les sujets — par exemple, prédire l'achat d'un nouveau produit : six mois d'observation avant le lancement, trois mois de résultat après. Tantôt elles sont définies relativement à un événement qui survient à des dates différentes selon le sujet. La fraude relève de ce second cas : pour chaque sinistre, l'observation est le temps avant l'événement (le comportement passé du déclarant), le résultat est le temps immédiatement après (au cours duquel on découvre si le sinistre est frauduleux).

Périodes alignées sur un ÉVÉNEMENT (★ = date du sinistre, propre à chaque ligne)

sinistre A   |---- observation ----★---- résultat ----|
sinistre B        |-- observation --★-- résultat --|
sinistre C  |------- observation -------★-- résultat -|

Après alignement (les mois sont définis RELATIVEMENT à ★) :

             [ ... obs(-3) obs(-2) obs(-1) ] ★ [ out(+1) out(+2) ]
                  descripteurs calculés ici       cible déterminée ici

Descripteurs et cible ne sont pas toujours tous deux temporels. Pour un modèle next-best-offer (meilleure offre suivante), les descripteurs couvrent tout le comportement passé jusqu'à l'appel du client, mais il n'y a pas de période de résultat. À l'inverse, pour la prédiction de défaut de prêt, il n'y a pas de période d'observation (tout vient du formulaire de demande) mais une période de résultat couvrant la vie du prêt.

Questions légales

Le praticien est parfois frustré qu'une législation l'empêche d'inclure une feature pourtant prometteuse. Deux principes s'appliquent presque partout. La lutte contre la discrimination interdit le traitement différencié sur des fondements protégés — sexe, âge, race, origine ethnique, nationalité, orientation sexuelle, religion, handicap, opinions politiques : un modèle de score de crédit ne peut donc pas utiliser la race comme descripteur. La protection des données personnelles ensuite, dont l'OCDE énonce huit principes ; trois importent pour l'ABT : la limitation de la collecte (données obtenues licitement, avec consentement), la spécification de la finalité (informer de l'usage au moment de la collecte) et la limitation de l'usage (ne pas réutiliser pour d'autres fins). Une compagnie qui collecte des données de voyage via une assurance voyage ne peut pas, sans accord préalable, les réutiliser pour tarifer une assurance-vie.

Implémenter les features

L'implémentation rend tangible la distinction brut / dérivé. Une feature brute se contente d'une copie de valeur. Une feature dérivée combine des données de plusieurs sources via quelques opérations récurrentes : joindre des sources, filtrer lignes et champs, dériver par combinaison ou transformation, et agréger. L'ensemble forme un processus extract-transform-load (ETL), opéré par les SGBD et les outils de manipulation de données.

Étude de cas : l'ABT de la fraude

Reprenons la fraude. Le concept Historique du déclarant est intrinsèquement lié à la période d'observation, et ses descripteurs sont temporels. Le sous-concept Fréquence des sinistres ne se résume pas à un simple compte : ajouter des features qui éclairent plus complètement un concept améliore le modèle. On inclut donc le nombre de sinistres passés, le nombre sur les trois derniers mois, la moyenne annuelle, et le ratio de cette moyenne au nombre des douze derniers mois.

Le sous-concept Types de sinistres met l'accent sur les blessures des tissus mous (le « coup du lapin » / whiplash), fréquemment associées à la fraude : on retient leur nombre, leur ratio aux autres sinistres, un drapeau « au moins un sinistre refusé », et une mesure de diversité des types de sinistres calculée par l'entropie (chapitre 4), qui résume bien la variété d'un ensemble en un seul nombre.

D'autres concepts sont atemporels. Les Détails du sinistre fournissent des features brutes (type, montant) et une feature dérivée — le ratio montant du sinistre / primes versées — bâtie sur l'idée qu'une fraude survient souvent tôt dans la vie d'une police. Un mapping convertit enfin l'adresse en région géographique interne. L'ABT finale est trop large pour tenir d'un bloc ; en l'examinant, on y repère déjà des valeurs étranges (−99 999) et des valeurs manquantes — l'évaluation de la qualité des données fait l'objet du chapitre suivant.

À retenir

• Un modèle prédictif ne résout pas un problème métier : il produit des éclairages qui aident à mieux décider. La première tâche, et la plus importante, est de convertir un problème métier en solution analytique en décrivant le modèle, son usage et son bénéfice.
• La faisabilité se juge sur la disponibilité des données (objets, connexions, granularité, volume, horizon) et sur la capacité de l'entreprise à exploiter les éclairages ; les meilleures solutions s'insèrent dans un processus existant.
• L'Analytics Base Table (ABT) est une table plate une-ligne-par-sujet : des descripteurs plus une cible unique, chaque ligne étant une instance du sujet de prédiction.
• On conçoit l'ABT en partant de concepts de domaine (abstractions du sujet) que l'on traduit en features ; souvent plusieurs features, voire des proxys, expriment un même concept.
• Les features sont brutes ou dérivées ; les dérivés courants sont les agrégats, drapeaux, ratios et mappings — un ratio vaut souvent mieux que ses composantes prises séparément.
• Pour les modèles de propension, on distingue période d'observation (descripteurs) et période de résultat (cible), parfois alignées sur un événement propre à chaque sujet.
• Gare à la fuite de données : hors la cible, tout descripteur doit être calculable avant l'événement prédit, sous peine d'un modèle parfait à l'entraînement et inutile en production ; et certaines features sont interdites par le droit (anti-discrimination, protection des données).