Quand les statistiques de l’Insee bégaient

Temps de lecture : 5 minute(s)

On pourrait penser, un peu naïvement, que le prestigieux Institut National de la Statistique et des Études Économiques (Insee), qui se trouve être le fournisseur des statistiques économiques officielles en France est une administration qui n’occupe que des gens brillants et méticuleux.   Des gens qui veulent que leurs données soient absolument irréprochables, puisqu’ils sont l’unique source officielle, notamment pour ce qui concerne les statistiques de décès.  C’est à eux directement que vont les remontées individuelles des décès envoyés par les mairies de tout le pays.

Seulement voilà, quand on regarde les fichiers de près et qu’on se pose la question de savoir si, par hasard, il ne s’y cacherait pas l’un ou l’autre doublon, on tombe de l’armoire.   Sur la période 1970-2020, soit 25.596.542 lignes au total, on trouve pas moins de 213.111 doublons.

Aux gens qui auraient eu le malheur de faire des études ou de rédiger des ouvrages en vous basant sur ces données sans au préalable les avoir sérieusement nettoyées, je dis que leurs travaux sont entachés d’erreurs à concurrence d’un peu moins de 1%.

Mais, me direz-vous, c’est tout simplement parce que l’Insee n’est pas au courant de ces erreurs, que ne les signalez-vous pas auprès d’eux afin qu’ils puissent les corriger!

Est un peu optimiste, ils savent pertinemment que leurs fichiers sont truffés d’erreurs et n’ont strictement rien fait pour les nettoyer de ce qui est clairement un gros paquet d’erreurs.  Non, corriger viendrait à reconnaître qu’on a publié des données bancales durant les 50 dernières années en parfaite connaissance de cause.

Avec les outils informatiques actuels, il est aisé de rendre la saisie des doublons impossible en plaçant une contrainte sur une clé composite, ce qui suppose toutefois d’éliminer préalablement les doublons de la table.

De même on peut interdire facilement d’encoder des gens dont la date de décès est antérieure à leur naissance, je pense?  Or on en trouve quand même 80, parfois morts des décennies avant leur naissance.

Si vous voulez une preuve que l’Insee est bel et bien au courant de l’existence (en masse) de doublons dans ses listes, consultez donc le site matchID du ministère de l’Économie qui est l’organe de tutelle de l’Insee. 

Dans la section à propos, on y détaille l’origine des données, le nombre d’enregistrements et… le nombre de doublons qui ont été nettoyés par les bons soins des informaticiens du ministère : 159.595 en date du 10 février 2021.

Euh, minute, vous avez dit qu’il y en a 213.111, là on parle de 159.595, ça fait quand même une différence de 53.516, comment vous expliquez ça?

Eh bien c’est très simple, même quand ils se sont mis en tête de supprimer les doublons, ils ont réussi à en louper 53.516.  Ils sont très forts…

Comment?  Eh bien une ébauche de réponse se trouve tout de suite après, on parle de « doublons (stricts) ».  Autrement dit, le gars qui a rédigé la requête s’est dit que ce serait une bonne idée d’inclure tous les champs dans le regroupement pour déterminer quels enregistrements sont des doublons.  C’est évidemment une erreur grossière, l’idée étant de partir de la contrainte la plus lâche possible, sans toutefois qu’elle puisse générer des faux positifs.

Imaginons que l’on décide de considérer comme doublons deux lignes qui auraient respectivement le même patronyme, les mêmes prénoms dans le même ordre, la date de naissance et la date de décès.  Ca a l’air d’une contrainte suffisante pour éviter les faux positifs, n’est-ce pas?  Il n’en est rien, prenons l’exemple suivant :

Ces deux-là sont bien selon toute probabilité des personnes différentes, mais elles ont toutes deux une date de naissance incomplète (jour et mois inconnus) et un seul prénom.  Du coup, l’efficacité de la contrainte s’effondre.

On va donc devoir considérer plus de champs dans cette contrainte.  Et c’est là que les informaticiens de l’Insee on fait un très mauvais choix, comme nous le verrons.  Moi j’ai ajouté le lieu de décès (qui est le code postal).  Pourquoi?  Parce que celui-là est indiqué par la mairie.  Les informaticiens du ministère ont, eux, ajouté le « numéro » d’acte de décès, qui n’est pas un numéro mais techniquement une chaîne de caractères, et très probablement aussi les autres champs (sexe, lieu de naissance, pays de naissance).

Et c’est là que les choses se gâtent, parce que c’est source d’erreurs, mais cette fois dans l’autre sens, leur application va passer à côté de tout un tas de doublons qui sont bien réels, prenons un exemple :

Si on lance cette recherche sur le site de MatchID, on trouve bel et bien 3 enregistrements, alors qu’on parle bien d’une seule et même personne.

Vous voyez à la deuxième ligne, dans le champ actedc la barre oblique après le 2574?  C’est interprété comme étant différent de 2574.  Pire, ce que vous ne voyez pas, il y a un espace avant le 2574 dans les deux dernières lignes.  Aucune n’est donc considérée comme strictement égale à aucune autre.  Pas de doublon, c’est magique!

Donc non seulement prendre le champ actedc est une mauvaise idée, mais d’une manière générale, considérer une chaîne de caractère sans lui appliquer un Trim() pour retirer les blancs avant et après est très stupide.

Je pense que la contrainte sur les champs : nomprenoms, datenaiss, datedc, lieudc est nécessaire et suffisante, suffisante pour ne laisser passer aucun doublon et nécessaire pour ne pas déclarer doublon deux fiches qui seraient en réalité des personnes distinctes.

Ah, une dernière pour la route, le record du nombre de lignes identiques, c’est Mme Marie CABRE, née le 04/01/1909 à Loos-en-Gohelle et décédée le 23/07/1999.  Elle s’y trouve pas moins de 40 fois.  À elle seule elle représente un pic dans les statistiques de mortalité du mois de juillet 1999.