LMDP: pas la bonne ligne

Ca faisait un bout de temps que j'avais envie de démarrer cette série. LMDP, c'est pour "Le meilleur du pire". Bon, je sais, comme nom de série, il y a sans doute mieux...

Depuis quelques années, je tiens une espèce de best of de pires bêtises que j'ai vue dans le milieu de l'informatique. Bien sûr, il y a du code, mais aussi de la gestion de projet (au sens large) et quelques inclassables.

C'est d'ailleurs par l'un d'eux que je vais commencer.

Le contexte

Tous les trois mois, nous migrons des clients d'une ancienne application vers une nouvelle. Tous les trois mois, un responsable de la migration nous demande de lui fournir des scripts SQL afin de reprendre les données de l'ancienne application vers la nouvelle.

Jusque-là, rien de très particulier.

Pour nous "aider", il extrait lui-même les données dans un fichier Excel. Chaque ligne du premier onglet représente une ensemble de données à insérer, parfois dans une, parfois dans deux tables.

Pour un des types de données, j'ai écrit une formule qui, copiée dans le deuxième onglet du document autant fois qu'il y a de lignes dans le premier, se transforme en requête SQL d'insertion. Je ne ferais pas ça tous les jours, mais bon...

Initialement, j'ajoutais la formule moi-même au fichier fourni par le responsable (appelons-le Antoine), mais comme ce n'est pas mon boulot, je lui ai dorénavant envoyé la formule afin qu'il bricole lui-même son fichier Excel. Et cela fonctionne très bien ainsi depuis plusieurs trimestres.

Première boulette

Quand je dis que tout se passe bien, ce n'est pas tout à fait vrai.

Le trimestre dernier, Antoine a demandé l'exécution de requêtes une première fois, puis s'est rendu compte que son fichier n'était pas complet, l'a complété, a généré les requêtes une nouvelle fois et a demandé une seconde exécution de ces requêtes.

Conséquence, des lignes dupliquées dans la base de données. Vous me direz que s'il y avait eu des contraintes d'unicité, ça ne serait pas arrivé, et vous auriez raison. A notre décharge, l'application vérifie que les lignes n'existent pas déjà et il paraissait impossible que ça arrive... jusque-là.

Nous décidons donc de revoir les requêtes de vérifier si la ligne n'existe pas déjà. J'effectue cette modification dans le dernier fichier fourni par Antoine.

Toujours dans l'urgence

Aujourd'hui, vers 10h, Antoine nous demande d'exécuter les scripts de migration. Petit vent de panique: la migration n'est normalement prévue qu'à la fin du mois et la moitié de l'équipe est d'ailleurs en congé, en particulier celui qui s'occupe d'une grande partie des migrations. Nous voudrions attendre mais rien à faire, les données doivent être migrées pour 12h, heure à laquelle les clients auront accès à la nouvelle application.

Néanmoins, on s'organise pour pallier le manque d'organisation d'Antoine...

Je lui rappelle que j'ai modifié la formule Excel. Il vient la voir sur mon PC, dans le fichier Excel de la dernière migration et me dit qu'il va m'envoyer le fichier, ce à quoi je réponds que je vais plutôt lui envoyer la formule. Avant qu'il ait eu le temps de réagir, j'ouvre un nouveau message et y copie la formule.

Là, il réagit et me dit: "envoie-moi aussi le fichier". Je lui réponds: "Tu dois plutôt utiliser la formule, c'est un ancien fichier". Il insiste et je la joins à l'e-mail.

Me voilà tranquille.

Deuxième boulette

Dix minutes plus tard, Antoine envoie un mail à l'équipe système pour exécuter un fichier de requêtes sql en production. Je suis en copie du mail.

Cinq minutes après, réponse de l'équipe système annonçant que les requêtes n'ont pas pu être exécutées.

Je jette un oeil au log d'erreur, puis aux requêtes envoyées par Antoine, et il apparaît que la dernière requête est incorrecte. Les paramètres qui devraient être insérés sont absents. J'en déduis que la formule a été copiée sur une ligne de trop, une ligne qui ne correspond à aucune donnée dans le premier onglet du fichier Excel.

Quelques minutes plus tard, nouveau mail d'Antoine, avec un fichier SQL, correct celui-là.

Bon, ce sont des choses qui arrivent...

Là où ça devient surréaliste, c'est que, après confirmation de l'exécution des requêtes en production, Antoine vient près de moi: "Il y avait un problème dans ton fichier. (Fichier qui est, je le rappelle, le sien, sur lequel j'ai ajouté la formule Excel). Tu commençais à la ligne 2 (Note: la première était un intitulé de colonne.). Le mien commençait à la ligne 1."

Ben tiens... CTRL+C, CTRL+V de la page de formule peut-être? Et tout ça directement en production, sans demander une simulation d'exécution en préproduction par exemple...