Quelle API pour quel usage

L'API décès possède deux principales fonctions:

• la recherche unitaire
• l'appariement (liste de personnes à rechercher)

La première sera utile dans un contexte utilisateur (un formulaire dte données de données d'État civil, où l'appel API servira à vérifier la vitalité d'une personne).

La seconde est utile pour compléter le statut vital d'une base de donnée clients au sein d'un système d'information, de plusieurs milliers à environ un million de personnes

La documentation de l'API est réalisée au format OpenApi Specification (OAS3, Swagger).

Elle décrit de façon détaillée les champs et leur format.

Intégration de l'API d'appariement à un backend

L'API unitaire est limité à une requête par seconde. Pour les appariement en masse, une API search/csv permette le traitement de 50 à 100 requêtes par seconde.

Cette API de soumettre un CSV contenant jusqu'à 1 millions d'identité (100Mo), qui sera complété d'éventuelles détections des données de décès en cas de correspondance celle-ci étant qualifiée par un score de confiance.

Ces données peuvent être retraitées à l'issue pour être injectées dans votre base de donnée.

L'exemple minimaliste suivant est réalisé en Python est disponible sur ce REPL.

Appariement sur deces.matchid.io, explications

Recherche des identités

La requête est composée d'un bloc de critères obligatoires (blocking), les autres éléments de la requête étant optionnels. Les critères obligatoires sont ceux-ci:

• "nom prénom" = "nom prénoms" INSEE
  modulo normalisation et tokenization : "olivier martin" = "martin olivier" =~ "jean olivier martin".
  Ce match tolère le flou : "oliver martin" = "olivier martin"
• si une date de naissance est une plage (e.g 01/01/1930-01/01/1940), elle devient obligatoire
• si une date lastSeenAliveDate est spécifiée, elle devient obligatoire

Note 1: si l'un des champs nom ou prénom manquent, tous les champs disponibles deviennent obligatoires, avec une tolérance floue.
Note 2: les données INSEE utilisent le nom de naissance. Le nom d'usage génère du silence (manqués), notamment sur la popuation des femme mariées.
Note 3: le code source des requêtes est sur GitHub.

Scoring

Le scoring est composé de trois composantes relatives aux données de l'identité pivot: nom & prénom, sexe, date et lieu de naissance.

Les champs textuels (nom prénom, libellés de commune et pays) sont traités en normalisation et tokenization, puis comparés avec la distance de Levenshtein, et sont pénalisés en cas de différence de sonorité (soundex-fr).

Le lieu de naissance prend en compte les trois paramètres éventuels (commune, département, pays) et effectue un traitement différencié en cas de naissance à l'étranger.

Les scores (nom+prénom, sexe, date, lieu) sont ensuite multipliés, et un coefficient de puissance est affecté selon le nombre de paramètres de match (moins il y a de champs soumis à requête, plus une erreur unitaire est pénalisante). Lorsque l'une des données n'est pas fournie, une faible pénalité est soumise (entre 50% et 100% selon le champ).

Le code source du scoring est également sur GitHub.

Intégration d'une UI de validation

Nous vous recommandons dans un premier temps de passer par le service en ligne pour tester la validité du fichier et du choix des colonnes à apparier avant d'attaquer le code d'appariement. Vous pourrez, en particulier, vérifier avec l'aide de l'UI de validation.

Dans le cas d'un service métier intégré dans un système d'information, pour des appariement réguliers, nous recommandons d'intégrer une UI de validation telle que celle proposée.En effet, l'UI proposée permet de diviser en moyenne par 10 le temps de validation d'une paire d'identité par rapport à un affichage en colonnes classiques sous un tableur.

Pour traiter un fichie de 100000 lignes, si 10% de personnes sont décédées, environ 9000 seront avec de très bon scores (peu utiles à valider à la main, sauf cas métier nécessitant une assurance complète), et 1000 seront à regarder plus précisément. Ces 1000 cas peuvent prendre moins de 30 minutes avec une UI adaptée, contre une demie jourée sur un tableur.

A ce stade, nous n'avons pas mis à disposition de composant réutilisable pour cette fonction. Néanmoins nos deux implémentations d'interface de validation peuvent vous inspirer: en Svelte.js ou en Vue.js.

Authentification

L'API est utilisable sans authentification pour un nombre limité d'appels sur l'API de recherche. Pour utiliser l'API au-dela d'une centaine d'appels, ou pour utiliser l'API d'appariement, l'utilisation d'un jeton est nécessaire, tout en restant gratuite.

Voici les étapes si vous voulez automatiser l'obtention de la clé d'API pour un an:

Étape 1 - Creation manuelle du jeton

• S'enregistrer et confirmer son identité manuellement sur deces.matchid.io
• Récupérer le jeton dans le menu d'utilisateur (en haut à droite) > API Key. La clé devrait commencer par eyJhbGc*

Ce jeton est valable 30 jours sans changement et permet de dériver de nouveaux jetons jusqu'à 12 mois. L'obtention d'un nouveau jeton (avec confirmation de mail) reste obligatoire tous les 12 mois.

Étape 2 - Automatisation pour un an

Vous pouvez rafraîchir votre jeton initial sans limite de la façon suivante:

• Pour tout appel à l'API: il suffit d'ajouter le Header: Authorization: "Bearer accessToken", en remplaçant accessToken par votre jeton. Des limitations demeurent sur la fréquence d'appel (1/s pour la recherche) mais le nombre d'appels devient illimité.
• Pour rafraîchir le jeton : avec ce même Header faire un GET sur https://deces.matchid.io/deces/api/v1/auth?refresh=true - ne nouveau jeton récupéré permettra de réitérer les opérations jusqu'à 12 mois.

Vous pouvez faire une demande de rafraîchissement tous les jours par exemple, il n'y a pas de limite (il est inutile d'en faire une demande a chaque appel, mais ce peut être à chaque session si vous faites des appels consécutifs de 5 minutes ou même moins).