Dans le cadre d’un projet client, l’ANFR, nous avons mis en œuvre des fonctionnalités de recherche de similarités sonores. L’idée était de limiter les doublons liés aux saisies des noms de famille par des opérateurs lors de réclamations créées à partir d’appels téléphoniques. En effet, il arrive régulièrement que les réclamants appellent plusieurs fois et la saisie des noms de famille est souvent problématique.

la phonétique pour valoriser les données

# Cas d’utilisation

M. Dupont appelle le service de l’ANFR pour signaler une anomalie. L’opérateur téléphonique enregistre la nouvelle fiche. Parmi les informations qu’il renseigne, on retrouve plusieurs critères sur lesquels s’appuie le rapprochement :

saisie initiale

Avant la validation de la fiche, un assistant de l’application suggère une anomalie qu’il a détectée :

suggestions de l'assistant
En effet, la veille, M. Dupond a appelé pour signaler une anomalie dans la même zone géographique. Après vérification, l’opérateur téléphonique crée un lien entre les deux fiches. Les données sont immédiatement valorisées si bien que les croisements ultérieurs sont facilités.

# Algorithmes employés

Plusieurs d’algorithmes intéressants existent. Nous nous sommes appuyés sur deux algorithmes que nous n’avons pas inventés :

  • Soundex fr est version francisée de Soundex. Ce dernier est un algorithme de calcul d’une signature phonétique d’une chaîne de caractères (deux chaînes proches ont la même signature).
  • Jaro-Winkler permet de calculer une distance entre deux chaînes de caractères. La résultat est comprise entre 0 (les chaînes sont très éloignées, i.e. complètement différentes) et 1 (elles sont similaires)

# Implémentation

Dans un souci de performances, nous réalisons les calculs au plus près des données car le volumétrie est importante. Nous avons choisi d’implémenter des fonctions PostgreSQL adéquates sur lesquelles s’appuient les prédicats JPA utilisés par l’application serveur Java lors de la consommation de web services.

# Côté PostgreSQL

L’implémentation de la version francisée de l’algorithme soundex est inspirée de la version soundex_fr de Damien Griessinger. Celle de Jaro Winkler a été réalisée pour l’occasion.

Au niveau de la base de données, on retrouve les deux fonctions suivantes :

Exemples de calcul d’empreintes Soundex fr :

Exemples de comparaison Jaro-Wrinkler :

Dans le projet en question, nous souhaitons récupérer les réclamations dont le nom du signalant a la même signature phonétique Soundex fr que ”Dupont” ou dont la distance Jaro-Winkler est supérieure ou égale à 0.75. La requête SQL ressemble au modèle suivant :

Remarque : pour optimiser les recherches en cas de volumétrie importante et d’utilisation régulière, il est préférable d’utiliser des index basés sur les signatures soundex_fr.

# Côté Java

Je ne m’attarde pas sur les détails dans ce paragraphe. Notons que nous utilisons JPA/Hibernate pour accéder aux données.

Dans un premier temps, nous enrichissons le dialecte Hibernate utilisé, qui dérive de org.hibernate.dialect.Dialect :

Puis nous pouvons utiliser les fonctions à travers des prédicats JPA. L’exemple SQL précédent peut s’écrire de la manière suivante :

# Pour continuer

La mise en place de ces mécanismes de recherche phonétique dans un projet métier nous a permis d’améliorer la qualité des données saisies très simplement en les valorisant. De plus, l’assistant a une vocation pédagogique. Les opérateurs sont plus vigilants lorsqu’ils saisissent les noms de famille car les erreurs sont mises en avant. Pour finir, l’assistant facilite l’apprentissage de l’anticipation des erreurs qui reviennent régulièrement, avec l’habitude.

Il ne reste plus qu’à imaginer les cas d’utilisations de ces algorithmes dans vos applications !