L’IA générative : utile pour nettoyer des données ?

Après une première expérience d’analyse d’un ensemble de données en utilisant des outils d’intelligence artificielle générative (GenAI), aux résultats impressionnants, nous nous sommes intéressés à un aspect fondamental pour tout analyste de données, en particulier dans le secteur des données administratives : la qualité des données. En adoptant une approche rigoureuse et systématique, nous avons analysé comment se comportaient des outils comme ChatGPT, Gemini, Copilot, Claude ou Mistral, quand il s’agissait, non plus simplement d’analyser des données, mais de les nettoyer. Nous avons choisi pour cette expérience un type de données que nous connaissons bien (1, 2) : les adresses en Belgique. Il existe bien évidemment des outils dédiés au nettoyage d’adresses, voire même au géocodage. Mais il nous paraissait pertinent d’évaluer les bénéfices ou défauts de cette nouvelle famille d’outils.

Comme nous l’avons déjà fait dans des articles précédents, nous sommes partis d’un jeu de données provenant de la Banque Carrefour des Entreprises. Plus précisément, nous avons utilisé un ancien jeu de données datant de 2016, la qualité de la source s’étant entre temps notablement améliorée ; mais pour évaluer les performances d’un outil de nettoyage, il est préférable de ne pas se baser sur des données trop “propres”. On ne teste pas les performances d’un lave-vaisselle avec des couverts déjà lavés… Ce jeu de données contenait +/- 266.000 adresses, pour la plupart en français, d’entreprises dans la région de Bruxelles-Capitale.

Nous avons tenté deux approches :

• En utilisant les versions “chat”, on envoie l’ensemble des adresses sous format CSV, accompagnées d’un “prompt” que nous détaillerons ci-dessous, qui pour l’essentiel demande de “standardiser ces adresses” et de fournir, outre un fichier Excel contenant le résultat, un script en Python permettant de le reproduire. C’est cette approche que nous décrivons dans cet article.
• En utilisant l’API, on envoie une séquence de “batch” d’adresses (en JSON), avec des instructions sensiblement similaires à celles de la première approche, mais simplifiées. Cette approche fera l’objet d’un prochain article.

Nous nous sommes posé diverses questions :

• Le processus était-il facile, ou semé d’obstacles ?
• Les instructions étaient-elles respectées ?
• Le processus était-il stable, ou, en d’autre termes, obtient on le même résultat si on refait la même demande à quelques heures d’intervalles ?

La difficulté principale de notre approche a été de définir le bon prompt. Le principe a été de fournir d’un seul coup un fichier “Markdown” contenant toutes les instructions que nous voulions voir appliquées.

Le fichier de données contenait une série de colonnes, pour les différentes informations suivantes : “rue” (StreetFR), “numéro” (HouseNumber), “code postal” (Zipcode), “municipalité” (MunicipalityFR). Mais de nombreuses adresses sont mal encodées. Par exemple :

• Le numéro se trouve dans le champ “rue”, en début (“20 Avenue Fonsny”) ou à la fin (“Avenue Fonsny 20”)
• Le noms sont abrégés (“Av. Fonsny”, “A FONSNY”…)
• La casse n’est pas uniforme (“Avenue Fonsny”, “AVENUE FONSNY”)
• De multiples variantes de la même rue existent (“Boulevard Albert II”, “Boulevard du Roi Albert II”, “Boulevard Albert 2″…)
• Si le numéro n’est pas pertinent, de nombreuses façons de l’indiquer existent : “SN” (sans numéro), “ZN” (zonder nummer), “S/N”, “?”, “*”…

Instructions

Dans le fichier d’instructions, nous avons décrit en détails deux phases de nettoyage. La première consistait à analyser chaque ligne individuellement. La seconde demandait de comparer des enregistrements “proches” pour tenter d’en sortir des variantes et fautes de frappe.

Phase 1 : nettoyage

Dans la première phase de nettoyage, on demande de créer trois nouvelles colonnes : “StreetFR_cleansed” et “HouseNumber_cleansed”, pour y placer la version nettoyée de ce qui se trouve dans “StreetFR” et “HouseNumber”, ainsi que “ExtraInfo_cleansed”, pour y mettre les informations que l’outil estime ne faire ni partie du nom de la rue, ni du numéro de maison (un étage, par exemple).

Pour le numéro de maison, nous demandons (entre autres) :

• De l’extraire du champ “StreetFR” s’il s’y trouve, en fournissant divers exemples ;
• De le standardiser, de sorte de ne pas avoir, par exemple, une fois “10 a”, une autre fois “10A”, ou encore “10/A” :
• De remplacer toutes les variantes de “sans numéro” par une valeur vide.

Pour le nom de rue, nous demandons :

• D’étendre les abréviations de préfix, principalement en français : “Av.”, “Blvd”, “Chée”… ;
• De tout mettre en “casse de titre” (title case), en veillant à garder en minuscule les articles et conjonctions : “Rue des Chats”, “Avenue de l’Indépendance”… ;
• De veiller à garder en majuscules les chiffres romains : “Boulevard Léopold II”, “Rue Charles VI”…

Instructions de la phase 1

In this first cleansing phase, your task is to create a cleansed copy of columns StreetFR and HouseNumber, which will be named “HouseNumber_cleansed”,  “StreetFR_cleansed”. An additionnal column “ExtraInfo_cleansed” will also be created.

In “HouseNumber_cleansed”, you will:

• In case of the format “20 A FONSNY” in StreetFR (all in upper case ; one number, one space, one letter in ‘A’, ‘R’, ‘C’, ‘B’, ‘S’ or ‘P’, one space, several letters or spaces): extract the number in ‘HouseNumber_cleansed’ ; Do the following street type replacement: A=Avenue ; R=Rue ; C=Chaussée ; B=Boulevard ; S=Square ; P=Place
• Extract housenumber from “StreetFR” if needed, put in “ExtraInfo_cleansed” additionnal information which doesn’t seem to be part of the house number. Extract number only at the beginning of the string (“20 Avenue Fonsny”) or at the end (“Avenue Fonsny 20” or “Avenue Fonsny, 30”), possibly followed by one letter (“Avenue Fonsny 20 A”), or with ranges (“Avenue Fonsny 20-22” or “Avenue Fonsny 20/22”), or with a box number indication (“Avenue Fonsny 20 bus 3”, “Avenue Fonsny 20 box 3”, “Avenue Fonsny 20 bt 3”, “Avenue Fonsny 20 bte 3”, “Avenue Fonsny 20 boite 3”).
• If you have to extract a housenumber “num1” from “StreetFR” but “HouseNumber” already contains a value “num2”, keep them both in “HouseNumber_cleansed” : “num2 / num1”
• Standardise in a safe way the housenumber. For instance, “20A”, “20 A”, “20a” or “20/A” should become “20A”. But do not replace “20/22” by “2022”
• Many values represent “no number” : “SN” (Sans numéro, in French), “ZN” (Zonder nummer, in Dutch), “S/N”, ‘?’, ‘-‘, ‘/’ and many others. Replace them by an empty string

In “StreetFR_cleansed”, you will :

• Standardise street names by expanding abbreviations. For instance “Av Fonsny”, “Av. Fonsny”, “Av.Fonsny” or “A Fonsny” should all become “Avenue Fonsny”. Use several variants : Avenue (Av, Ave, A), Chaussée (Ch, chée), Boulevard (B, Bd, blvd, bvd), Rue (R), Place (Pl), Square (Sq). Replace those pattern only at the begining of the sentence, or if they are only preceded by numbers. Replacement should always be followed by a space.
• Trim heading or leading spaces, and collapse consecutive spaces.
• As described in the previous section, extract housenumber and put them in HouseNumber_cleansed
• Set all words in title case, excepts determiner (le, la, les, du, des, aux, de…).
• Roman numbers should be in uppercase
• Remove all variants of “no number” (‘SN’, ‘ZN’, ‘S/N’, ‘*’, ‘?’, ‘-‘, ‘/’ and many others), at the end of the string and isolated (Not in “FonSNy”)

Phase 2 : déduplication

Dans cette seconde phase, nous tentons d’identifier des variantes du même nom de rue. Par exemple, si, pour un même code postal, on trouve “Rue V. Horta” dans un enregistrement, et “Rue Victor Horta” dans un autre, on gardera la version la plus complète pour l’ensemble. Le fichier d’instructions fournit de nombreuses précisions et exemples (comme, par exemple, de ne pas fusionner “Boulevard Léopold II” avec “Boulevard Léopold III”), que nous ne détaillerons pas ici.

Instructions de la phase 2

In this second phase, you will be more aggressive in the cleansing of street names, and take more risks. Output of this second phase will be in column “StreetFR_cleansed2”. This column will be computed starting from “StreetFR_cleansed” and will:

• If an initial can be expanded from other values within the same zipcode, do it. For instance : “rue V. Horta, 1160 Auderghem” in one record, “rue Victor Horta, 1160 Auderghem” in another, keep the longest one for both. In this case, the extension from an initial to a full name should be the only change. Do not map “Avenue V. Horta” to “Rue Victor Horta”. Do not map “Rue V. Van Horta” to “Rue Victor Van Fonsny”.
• Within different street names sharing the same zip, cluster spelling variants, keeping in “StreetFR_cleansed2” the most frequent value. For instance, if we have, for zipcode 1060, 100 times “Avenue Fonsny” and once “Avenue Fonsmy” or “Avenue Fonsni”, keep “Avenue Fonsny” in StreetFR_cleansed2.
• Before comparing strings, always remove street type (Avenue, Boulevard, Rue, Place, Square, Chaussée…) at the beginning of the street name. But do not map a street on a street with another street type.
• Similarity should be at least 0.9
• If the only difference between two street names is a diacritic symbol or punctuation, keep the most frequent one even if they don’t share the same zipcode : “Chaussée de Wavre” vs “Chaussee de Wavre” or “Chaussée de Wavre,”
• Be aware of roman numbers : “Boulevard Léopold II” should not be merged with “Boulevard Léopold III”

Résultat à produire

On demandera en conclusion :

• De fournir un listing téléchargeable au format Excel, en y ayant ajouté les colonnes calculées ;
• De générer un ou plusieurs scripts en Python, lisibles et documentés, permettant d’effectuer le nettoyage.

Comparaison

Nous avons soumis le même jeu de données avec le même fichier Markdown d’instruction à une série d’outils, plusieurs fois et à quelques heures d’intervalle. Nous avons ensuite :

• Analysé chaque listing produit pour s’assurer que les instructions étaient bien suivies ;
• Comparé deux listings produits par le même outil pour évaluer la constance du travail ;
• Exécuté le script Python généré pour vérifier qu’il était exécutable et produisait bien le même résultat que le listing généré directement par l’outil.

Les outils que nous avons considérés sont les suivants :

• ChatGPT (OpenAI, forfait “Plus”), modèle GPT 5.6 Thinking ;
• Gemini (Google, forfait “Pro”), modèle 3.1 Pro ;
• Copilot (Microsoft, forfait “Base”, gratuit), modèle GPT 5. Nous avons par ailleurs également testé une version “Pro”, intégrée dans Excel et Github
• Claude (Anthropic, forfait “Free”), modèle Sonnet 5 Medium
• Mistral (forfait “Free”), “Réflexion”

Un premier aperçu de chaque listing donne une impression positive : en regardant les changements effectués entre les colonnes d’entrée et de sortie, ils semblent majoritairement pertinents. On pourrait donc estimer que ces outils “font leur job”. Mais en approfondissant un peu, la situation n’est pas aussi reluisante.

Constance

Le premier aspect qui étonne est le manque de constance de outils. Aucun des outils n’a effectué les mêmes opérations sur les données au cours des trois évaluations successives (avec, rappelons-le, le même modèle, les mêmes données, le même prompt). Voici par exemple le pourcentage de changements entre la rue d’entrée et la rue modifiée à l’issue de la phase 2 :

	Essai 1	Essai 2	Essai 3	Delta
ChatGPT	5,44%	6,97%	8,41%	2,97 %
Gemini	9,62%	5,76%	9,84%	4,08%
Copilot	16,20%	0,27%	13,52%	15,93%
Claude	5,28%	5,22%	5,30%	0,08%
Mistral	32,22%	20,69%	99,79%	79,10%

La colonne “Delta” indique la différence entre la plus grande valeur et la plus petite : il correspond donc (virtuellement) à la proportion d’adresses que l’essai le plus “prudent” n’a pas modifiées, alors que la variante la plus “agressive” l’a fait. On peut donc observer une remarquable constance entre les itérations de Claude, voire de ChatGPT, là où Copilot et surtout Mistral semblent avoir fait des choix radicalement différents face au même problème.

En terme de constance, s’il suffisait en général d’envoyer en une seule requête les données et les instructions pour pouvoir directement télécharger le fichier nettoyé et le script, ça n’a pas toujours été le cas. Par exemple, à la seconde itération de Copilot, le script généré était vide. Il a fallu “négocier” (3 demandes successives) pour finalement l’obtenir. Dans une phase précédente de notre étude, Gemini a pu correctement générer le fichier demandé lors d’une première tentative, mais a bloqué lors de la seconde : il a prétendu qu’il lui était impossible d’exécuter du code Python dans son environnement. Nous avons beau eu lui dire qu’il en fut capable quelques heures avant, rien n’y fit. Il nous a fallu démarrer une nouvelle session pour à nouveau y arriver.

Exécution

Nous avons, pour chaque test, exécuté le script Python généré et comparé avec le listing reçu.

Pour ChatGPT, rien à signaler : les scripts s’exécutent en +/- une minute, produisant un résultat rigoureusement identique au listing.

Pour Claude, c’est également presque un sans-faute : une exécution légèrement plus longue (+/- 5 minutes), deux itérations produisant un résultat strictement conforme, et une avec 12 différences très légères, résultat chaque fois d’alternatives équivalentes.

Chez Gemini, le bilan est plus contrasté : le premier script entrait dans une boucle infinie ! Le second produisait un résultat conforme, le troisième 70 différences.

Avec Copilot, c’est encore un peu plus problématique : pour l’un des tests, nous n’avons tout simplement pas réussi à obtenir le script. Pour un autre, il était directement disponible, et pour le 3^ème, nous l’avons obtenu après négociations. Les deux scripts ont produit respectivement 637 et 810 lignes différentes par rapport au listing correspondant.

Sur cet aspect, la palme du mauvais élève revient à Mistral (mais, pour rappel, avec un compte gratuit) : c’est le seul qui n’a jamais pu directement générer un listing, mais uniquement un script en Python. L’un deux n’était par ailleurs pas complètement en Python, mais contenait des instructions en Javascript. Après lui avoir fait remarquer, Mistral a corrigé son code, mais n’était toujours pas exécutable. Ce n’est que la troisième version que nous avons pu exécuter. Lors d’un de nos autres tests, le code ne contenant pas un “import” nécessaire. Par ailleurs, le temps d’exécution variant de 6 à … 50 minutes !

Indicateurs

Nous avons ensuite parcouru les différentes instructions pour évaluer à quel point elles étaient respectées.

“Sans numéro”

Dans nos instructions, nous avons donné 7 valeurs correspondant à l’absence de numéro dans une adresse (‘SN’, ‘ZN’, ‘S/N’, ‘*’, ‘?’, ‘-‘, ‘/’), en précisant qu’il y en avait d’autres. Certains n’en ont identifié aucune (2^ème test Copilot), d’autres jusqu’à 19 (2^ème test Claude). Aucun outil n’a identifié les mêmes valeurs lors de ses différentes itérations.

Casse

Nous demandions en sortie de modifier la casse du nom de rue de façon un peu subtile : une casse de titre (title case, première lettre de chaque mot en majuscule, les autres en minuscules), mais avec une contrainte supplémentaire : garder les déterminant (de, la, des…) en minuscules. Nous devrions donc avoir “Rue de Sainte-Anne”, et non “Rue De Sainte-Anne” ou “Rue de Sainte-anne”. Nous avons observé plusieurs situations :

• L’absence totale de correction, gardant la casse originale (2^ème test Copilot) ;
• Une mauvaise gestion des tirets (“Rue Sainte-anne”) ou apostrophe (“Chaussée D’ixelles”). Étonnant, alors que la fonction “title” de Python aurait écrit “Rue Sainte-Anne” et “Chaussée D’Ixelles” (il “suffisait” ensuite de mettre le déterminant “D” en minuscules). On a également observé certaines incohérences dans un même listing, comme “Sainte-Anne”, mais “Grand-place” ou “Eglise-saint-pierre” ;
• Un des tests de Mistral a mis en évidence une implémentation hasardeuse : chaque mot commençant par un déterminant (“de”, “la”, mais aussi “d” ou “l”) était mis en minuscules.

Chiffres romains

En complément de la correction de casse décrite ci-dessus, nous avons demandé à ce que les chiffres romains restent en majuscules. On retrouve ceux-ci principalement dans des noms de rois Belges (Albert II, Léopold I, II ou III), ou étrangers (Joseph II, Charles VI…) ou même des Papes (Léon XIII). Ceci a été pour presque tous les outils correctement implémenté. On observe principalement des différences dans la façon de gérer les cas limites :

• On a à Bruxelles une “Rue Vilain XIIII”. Or, 14 s’écrit souvent “XIV” et non “XIIII”. Ceci explique sans doute pourquoi dans près de la moitié des cas, celle-ci a été reprise comme “Rue Vilain Xiiii” ;
• Des mots comme “midi” ou “dix” ont été considérés par certains outils comme des chiffres romains et mis en majuscule (bien que MIDI ne soit pas un nombre valide, contrairement à DIX). Mais étant donné que les chiffres romains dans les noms de rues représentent en général des valeurs relativement petites, il pourrait être raisonnable de ne pas y inclure “M” (1000) pour “D” (500). Cette observation nous a permis d’identifier principalement trois implémentations :
  • Une simple expression régulière listant les caractères autorisés : [IVXLCDM]+ ; c’était le cas de la première itération de ChatGPT, de Copilot ou de Mistral. Dans notre jeu de données, DIX et MIDI sont donc considérés comme des chiffres romains, mais on pourrait imaginer d’autres mots (Civil, Mix, Vil, Il, Clic….)
  • Une liste de valeurs acceptables (‘I’, ‘II’, ‘III’, ‘IV’ …), optée par Gemini, ou une des implémentations de CoPilot
  • Une expression régulière complexe, beaucoup plus précise, pour deux implémentations de ChatGPT ou Claude, avec pour l’une d’elle une liste additionnelle d’exclusions (contenant “midi” et “dix”).

Extraction de numéro

L’extraction du numéro intégré au nom de rue (“20 Avenue Fonsny”, “Avenue Fonsny 20” ou “Avenue Fonsny, 20”) a montré une grande variété d’implémentations. Si ChatGPT ou Claude n’ont pas rencontré de difficulté notable, les autres ont tous buté sur des cas particuliers plus ou moins subtils. Par exemple, deux des trois essais de Gemini ont échoué à identifier des cas comme “Avenue Fonsny, 20 A”). La second itération de Copilot n’a extrait aucun numéro en tête, et aucune n’a pu identifier le cas “…, 20 A”). Mistral a un bilan très mitigé.

Préfix

Les situations de type “Av. Fonsny” ou “A Fonsny” (à corriger en “Avenue Fonsny”) ont également été implémentées de façon très variable. La 3^ème itération de ChatGPT est passée complètement à côté de l’objectif. Une “Petite rue des Loups” est ainsi devenue “Place Etite Rue des Loups” ; “Abbaye de la Cambre” a été transformé en “Avenue Bbaye de la Cambre”

Phase 2

La seconde phase consistait à identifier des petites variantes entre deux noms de rue au sein du même code postal, pour ensuite remplacer la valeur la moins fréquente par la plus fréquente. Si nous rencontrons par exemple 10 occurrences de “Rue Sainte-Anne” et une de “Rue Sainte Anne”, nous remplaçons cette dernière par la variante avec le tiret. La difficulté de cette phase est de déterminer les méthodes et les seuils de comparaison. Si plusieurs tests ont tout à fait tiré leur épingle du jeu, ça n’a pas toujours été le cas. Principalement, plusieurs fusions “agressives” ont été observées. Comme “Rue des Chalets” changé en “Rue des Chats” ; “Rue des Barques” en “Rue des Briques”, ou “Rue des Ramoneurs” en “Rue des Rameurs”. Mais certains semblent avoir été encore plus permissifs : Gemini a ainsi changé “Rue de la Fontaine” en “Rue de la Montagne” ; “Rue Américaine” en “Rue Africaine”, ou “Rue Vergote” en “Rue Verte”.

Notons par ailleurs que Copilot n’a tout simplement, dans aucune itération, implémenté cette phase. Après avoir insisté pour le faire, nous avons observé une implémentation tout à fait hasardeuse. On y a observé uniquement des changements de type de rue (“Place Saint-Vincent” devenant “Rue Saint-Vincent” ; “Rue de Louvain” devenant “Chaussée de Louvain”), sans tenir compte du code postal. Soit l’exact inverse de ce qui avait été demandé. Par ailleurs, plusieurs éléments de la première phase qui étaient au point dans la première implémentation ne l’étaient plus dans celle incluant les deux phases.

Du côté de Mistral, ceci a été encore pire. Le premier test n’a fait d’autres corrections que des changements de casse ou de ponctuation ; le second a effectué de nombreux changements tout à fait inappropriés (“Rue de Rome” -> “Rue de Mérode” ; “Rue des Trois-Tilleuls” -> “Rue du Loutrier”…), ceci pour 650 valeurs, soit trois fois plus que les changements observés chez les bons élèves ; le troisième semble avoir tout simplement mélangé l’ensemble des valeurs, avec des changements complètement aléatoires pour chaque valeur. Ceci explique le taux de changements de 99,83 % du tableau ci-dessus.

Notons que standardiser les valeurs d’un jeu de données en observant les variantes internes n’est clairement pas la meilleure approche : il est nettement préférable, quand c’est possible, de comparer les valeurs à une base de référence, qui, dans ce cas-ci, consisterait en la liste de tous les noms de rue avec leur orthographe officielle.

Évaluation chiffrée

De sorte à pouvoir comparer de façon globale les itérations, nous avons identifié une trentaine de critères que nous avons évalués sur chacune des 3 itérations des 5 outils considérés. Pour certains critères, nous avons attribué 2 points s’il était correctement implémenté ou presque ; 1 point s’il l’était partiellement et 0 s’il ne l’était pas du tout ou très mal. Certains autres critères ont été évalués de façon numérique, comme par exemple le nombre de valeurs identifiées comme “sans numéro”. Pour ce type de critères, nous les avons transformés en une échelle de 0 à 2. Nous avons ensuite sommé ces différentes valeurs pour obtenir un score. Ce score global n’est donc pas un pourcentage et n’a pas de signification en soi. Il nous permet simplement de comparer, avec un certain degré d’objectivité, les différentes exécutions des différents outils.

Le tableau ci-dessous reprend deux informations : le score moyen observé sur les 3 itérations du même outil, ainsi que sa déviation standard. Il va de soi qu’il faut prendre ces mesures avec des pincettes, étant donné qu’elles ne se rapportent chacune qu’à trois valeurs. Mais elles permettent néanmoins d’objectiver dans une certaine mesure nos observations. Un score plus élevé indique un meilleur respect des consignes. Une déviation standard plus faible indique une meilleure cohérence entre les exécutions du même outil.

Le graphique ci-contre reprend deux informations : le score moyen observé sur les 3 itérations du même outil (hauteur de la barre bleue, ainsi que les valeurs), ainsi que l’écart entre le plus petit et le plus haut score observé (ligne orange). Il va de soi qu’il faut prendre ces mesures avec des pincettes, étant donné qu’elles ne se rapportent chacune qu’à trois valeurs. Mais elles permettent néanmoins d’objectiver dans une certaine mesure nos observations. Un score plus élevé indique un meilleur respect des consignes. Une écart plus faible indique une meilleure cohérence entre les exécutions du même outil.

Ces chiffres confirment le sentiment que notre analyse nous avait montré. Claude est nettement vainqueur, tant en terme de score global que de stabilité. Il est suivi de peu par ChatGPT. On observe ensuite sensiblement derrière, au coude à coude, Gemini et Copilot, et loin derrière Mistral. Rappelons qu’il s’agit de la version gratuite, mais c’est également le cas pour Claude.

Sentiment général

Notre sentiment général lors de cet exercice est que globalement, on a l’impression d’avoir à notre disposition un développeur junior, très rapide, certes, mais moyen et derrière lequel il faut être continuellement. Il fait plein d’erreurs, manque de constance. Si on lui demande de corriger un problème, il y a beaucoup de chances qu’il en introduise en même temps d’autres dans une toute autre partie du code. Si on lui demande deux fois la même chose, il fait parfois des choix radicalement différents.

Clairement, l’approche simple (envoyer d’un bloc toutes les instructions, en se fiant au code produit) ne marche pour aucun des outils, en tout cas pour le cas d’utilisation présent. À minima, il faut demander plusieurs fois la même chose, pour évaluer le résultat et combiner les meilleurs morceaux de chaque outil. Mais le temps qu’il nous a fallu pour mettre en place cette analyse comparative, identifier les problèmes, les objectiver, a probablement été proche du temps que nous aurions mis pour écrire le script intégralement.

Peut-être que notre prompt mérite des améliorations. Peut-être contenait-il trop d’instructions, et aurions-nous dû adopter une démarche plus itérative, mais cela aurait notablement compliqué les comparaisons. La demande de ne pas uniquement nettoyer des adresses, mais de fournir le script pour le faire, permettant ainsi une réutilisation, rajouter bien sûr une contrainte aux outils. Dans de futurs travaux, nous ferons sauter cette contrainte. Une approche plus “agentic”, ou un agent pourrait demander plusieurs scripts et les comparer, peut probablement s’avérer bénéfique.

Notons que nous avons également tenté une amélioration : nous avons demandé à ChatGPT “How to improve the attached prompt to make sure ChatGPT implements correctly all instructions?“. Il a adapté notre fichier d’instructions, pour être beaucoup plus précis et détaillé. Il en a résulté un fichier trois fois plus volumineux. Mais ça n’a malheureusement pas vraiment amélioré la situation, bien au contraire. Copilot a tout simplement abandonné aux deux premières tentatives. À la troisième, il nous a fourni un listing, mais pas le script. Gemini a été en mesure de générer un script (dont deux sur trois qu’il a fallu modifier pour qu’ils s’exécutent), mais jamais de l’exécuter. Et nous avons à nouveau observé de grandes différences entre les différentes itérations du même outil.

Par ailleurs, pour cette problématique précise de nettoyage d’adresse, il existe de nombreux outils classiques très efficaces pour réaliser cette tâche. La tendance du “tout à l’IA” que l’on observe de plus en plus mérite sans doute d’être modérée. À l’heure des feux de forêts massifs, des canicules à répétition et des inondations dévastatrices, se servir d’outils considérablement plus consommateur en énergie et en eau que des méthodes classiques et éprouvées, plus stables et souvent plus efficaces, est de toute évidence une approche à remettre en question.

L’informatique de demain doit sans nul doute faire une place majeure à l’IA générative, qui a une plus-value incontestable à bien des égards. Mais sans pour autant le faire de façon aveugle et mettre à la poubelle les méthodes traditionnelles qui restent pour de nombreux aspects clairement plus performantes. Il faut par ailleurs être conscient du manque de constance de ces outils. Ce n’est certes pas un problème dans de nombreuses situations, mais peut l’être pour certaines, en particulier quand un choix peut avoir des conséquences juridiques ou médicales.