Quand les statistiques de l’Insee bégaient

Temps de lecture : 4 minutes

 

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 :

nomprenom sexe danaiss lieunaiss commnaiss paysnai datedc lieudc actedc
DJEDDI*HAYETTE/ 2 19400000 99352 BEJAIA ALGERIE 19981028 13055 000000008
DJEDDI*HAYETTE/ 2 19400000 99352 BEJAIA ALGERIE 19981028 13209 171      

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 :

nomprenom sexe danaiss lieunaiss commnaiss paysnai datedc lieudc actedc
LIMOGES*REINE MELANIE LOUISE/ 2 19060801 34051 CANET   19931007 34172 2574     
LIMOGES*REINE MELANIE LOUISE/ 2 19060801 34051 CANET   19931007 34172  2574/   
LIMOGES*REINE MELANIE LOUISE/ 2 19060801 34051 CANET   19931007 34172  2574    

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.

avatar

Philippe Huysmans

Webmaster du Vilain Petit Canard, citoyen de nationalité belge, né à Schaerbeek le 16.10.1966. Marié et père de deux enfants. Je vis en Belgique et j’exerce la profession d’Informaticien à Bruxelles. Mes articles

Vous aimerez aussi...

6 réponses

  1. JR dit :

    Bonjour Monsieur.

    Pour Mme Marie CABRE la correction semble avoir été faite, les 40 occurrences étant trop « visibles ».

    Il faut comprendre que ces anomalies sont probablement dues au fait qu’une seule personne génère et s’autocontrôle lors de la mise en place de tels algorithmes de calcul. La mise en place de l’informatique à l’INSEE est ancienne et il m’étonnerait que le développement des applicatifs « historiques » soit aujourd’hui le fait d’une équipe. L’infaillibilité individuelle n’existe pas.

    Autre biais : les mairies (au bas mot quelques dizaines de milliers de services informatisés disparates) transmettent des données très souvent brutes de décoffrage qu’il est parfois nécessaire de remettre d’aplomb.

    En effet quelle est l’importance stratégique pour une collectivité territoriale « autonome » que la transmission des telles données : les 40 Marie CABRE proviennent plus certainement de plusieurs notifications que de doublonnages dans le traitement des données.

    Même remarque que la votre : ça ne devrait pas rester « invisible » pour l’INSEE.

    Les applications anciennes étaient écrites par des personnels aux compétences individuelles (l’ancienne école de l’informatique), mais tout évolue surtout leur âge.

    Cette réalité historique s’efface par la mise en place de plateformes dédiées au développement en équipes de personnels issus d’école d’informatique et où des méthodes de contrôles standardisés doivent pallier à ces « erreurs » de logique : tout d’abord dans le développement de nouveaux applicatifs, puis dans la réécriture des anciennes applications.

    J’étais dans ce bain pendant 40 ans je sais de quoi je parle (pas à l’INSEE). Dans mes dernières années je passais plus de temps à mettre en place des procédures de tests que de temps à l’écriture de nouveaux algorithmes, tous standardisés dans l’écriture des nouvelles applications.

    Petit exemple « historique » : un ordonnateur transmet des données de mandatement. Premier passage avec une série de numéros de mandats, puis la même chose avec de nouveaux numéros de mandats. Je peux vous mettre au défit de voir l’erreur sur une clef qui est basée sur le numéro de mandat. Il va de soit que des mesures logicielles ont été mises en place pour éviter la répétition de cette anomalie qui plus souvent que parfois n’en est pas une.

    Maintenant il est évident que vos constations devraient avoir le mérite d’être remontées vers les services informatiques de l’INSEE pour qu’une mise à jour soit faite.

    En espérant de surcroit qu’il ne se vexent pas de la leçon d’informatique que vous leur donnez 😉

    • Penser que l’informatique à l’Insee ce sont des ordinateurs datant des années 70 et que c’est une seule personne qui écrit (et vérifie) les algorithmes de validation est un peu risible.

      Non les multiples doublons comme Marie Cabre ne peuvent en aucun cas résulter d’un envoi multiple de la Mairie, parce que c’aurait figuré sur le même formulaire papier, et que le Maire valide (et signe) avant que celui-ci soit envoyé à l’Insee (Nantes). Les décès doivent être remontés endéans les 7 jours, c’est la loi qui le prescrit.

  2. Remo Zandonà dit :

    Bonjour Philippe,
    Lecture du jour, très intéressante information !
    http://russiepolitics.blogspot.com/2021/02/billet-du-lundi-in-covid-we-trust.html
    Bonne ap. midi à tous.

  3. Remo Zandonà dit :

    Bonjour Philippe,
    La lecture du jour.
    https://www.dedefensa.org/article/la-covid-a-larme-blanche
    A bientôt.

  4. Remo Zandonà dit :

    Bonjour Philippe,
    Lecture du jour qui n’augure rien de bon …
    http://russiepolitics.blogspot.com/2021/02/billet-progressiste-israel-officialise.html
    Bon WE. malgré tout.

  5. remo Zandonà dit :

    Bonjour, Petite lecture du jour très rafraichissante, comme une petite musique printanière !
    https://lesakerfrancophone.fr/les-trois-virus-biologique-informatique-et-ideologique
    Bonne lecture et bonne journée.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *