IA ou pas IA : le dilemme d’un développeur SIG

July 29, 2026

L’automatisation par l’IA est certes puissante, mais l’utiliser sans exercer son discernement géospatial comporte les mêmes risques que de recourir à du code copié ou à des outils hérités. Les développeurs SIG d’aujourd’hui doivent non seulement maîtriser les outils d’IA, mais aussi savoir quand les utiliser et comment en évaluer les résultats. Dans ce billet, André Piasta, formateur principal certifié ArcGIS à Esri Canada, explique pourquoi il est essentiel que les spécialistes des SIG continuent d’exercer leur discernement à l’ère de l’IA.

Points clés

L’automatisation par l’IA est certes puissante, mais l’utiliser sans exercer son discernement géospatial comporte les mêmes risques que de recourir à du code copié ou à des outils hérités. Les développeurs SIG d’aujourd’hui doivent non seulement maîtriser les outils d’IA, mais aussi savoir quand les utiliser et comment en évaluer les résultats.
La question n’est pas de savoir si l’IA écrira du code SIG : c’est déjà le cas. La véritable question est de savoir si les spécialistes des SIG resteront les gardiens de l’expertise géospatiale, en mettant à profit leur pensée critique, leur jugement et leur expérience.

IA ou pas IA : telle est la question.
Y a-t-il plus de noblesse, en codant, à endurer
Les jointures, les boucles et les scripts qui s’éternisent jusque tard dans la nuit,
Ou à s’armer contre une marée de données matricielles
Et, par l’automatisation, y mettre fin?

Si le Hamlet de Shakespeare était développeur SIG, il ne ferait pas les cent pas sur les remparts d’Elseneur, mais devant un bureau à deux écrans baigné d’une lueur bleutée : Python sur l’un, une carte qui refuse obstinément de s’afficher sur l’autre. Le fantôme qui lui rendrait visite ne serait pas celui de son père, mais celui d’un script hérité : un ancien flux de travaux ArcPy, aussi fragile que du verre, murmurant des histoires d’outils obsolètes, de chemins codés en dur, d’hypothèses tacites et de projections appliquées sans la moindre explication. « Souviens-toi de moi », chuchote-t-il depuis une géodatabase que personne n’ose remanier.

Sur un fond de couleur claire, une main à la peau claire tient un crâne coiffé d’un bonnet de bouffon à trois pointes.

Une question s’impose…

Les développeurs SIG d’aujourd’hui sont confrontés à un nouveau dilemme. D’un côté, il y a le savoir-faire : comprendre les jointures spatiales, les systèmes de coordonnées, les environnements de géotraitement, la provenance des données, la précision, l’échelle, la topologie, et savoir pourquoi une zone tampon qui semble juste dans une projection peut induire en erreur dans une autre. De l’autre côté, il y a l’IA, prête à rédiger des scripts, à suggérer des requêtes SQL, à classifier des images, à générer des essais et à transformer une demande formulée en langage courant en un flux de travaux exécutable avant même que le café ait refroidi.

La tentation est bien réelle. Pourquoi programmer manuellement l’extraction d’entités lorsqu’un modèle peut ébaucher le flux de travaux en quelques minutes? Pourquoi se débattre avec l’ordre des paramètres, les expressions régulières ou les vérifications répétitives des schémas de données lorsqu’un assistant peut produire une première version sur demande? Pour des équipes SIG déjà surchargées, l’IA et l’automatisation paraissent être une délivrance : moins de tâches manuelles, des chaînes de traitement plus rapides, des journaux d’exécution plus clairs, davantage de temps pour l’analyse et moins de temps à chercher pourquoi une fusion a produit dix mille entités au lieu d’une seule.

Et pourtant, c’est là que réside toute la difficulté. En SIG, le code n’est jamais simplement du code. C’est la géographie traduite en logique. Un script peut s’exécuter sans erreur et pourtant produire un résultat erroné : mauvais système de coordonnées, mauvaise transformation de système de référence géodésique, mauvaise unité de distance, mauvaise étendue d’analyse, mauvaise cardinalité de jointure ou hypothèses erronées sur les géométries nulles, la protection des renseignements personnels, les droits d’accès ou la sensibilité des données. En SIG, un message d’exécution réussie n’est pas synonyme de vérité.

Exécuter un code que l’on ne comprend pas, c’est ouvrir la porte à une trahison discrète. Rien ne garantit qu’il échouera de façon spectaculaire. Il se peut même qu’aucun message d’erreur n’apparaisse. Il peut produire une carte, une table, un service, un tableau de bord ou une couche d’aide à la décision qui inspire une confiance absolue. Mais si le développeur est incapable d’expliquer ce que fait le code, pourquoi il le fait, sur quelles hypothèses il repose, quelles données il considère comme fiables et quelles conséquences il pourrait entraîner, alors ce code est devenu Claudius : couronné par la commodité, à l’abri de tout examen critique… et dangereux.

Sur les remparts d’un château médiéval, un homme habillé de sombre, dans un costume de la Renaissance, se tient face à un esprit argenté vêtu d’une longue robe et coiffé d’un casque orné d’ailes. Derrière lui se tiennent deux gardes, l’un en jaune et l’autre en rouge.

En SIG, nous sommes souvent hantés par les vestiges fantomatiques légués par nos prédécesseurs.

Le code SIG généré par l’IA peut inventer des bibliothèques, des paramètres d’outil ou des systèmes de coordonnées, mal gérer les exceptions, écraser des résultats, exposer des identifiants, traiter incorrectement des jetons d’authentification ou contourner les autorisations. Il peut recommander des raccourcis qui fonctionnent dans un tutoriel, mais échouent en production. Il peut traiter des données géospatiales sensibles comme si elles étaient sans risque. Il peut faire passer un flux de travaux plausible pour un flux de travaux que l’on peut véritablement défendre. Et parce qu’il s’exprime souvent avec assurance, il peut donner à l’incertitude l’apparence d’une certitude.

Le danger ne se limite toutefois pas à l’IA. Le même risque se cache dans les scripts copiés, les carnets empruntés, les extraits de code anonymes, les anciens modèles exportés de ModelBuilder et les outils transmis d’un collègue à l’autre comme des reliques d’un autre âge. Utiliser un outil sans en comprendre la raison d’être, les limites, les dépendances et les conséquences, c’est confondre la possession avec la maîtrise. Un outil de géotraitement, comme l’épée qu’Hamlet tient à la main, doit être compris avant d’être dégainé.

Sur un fond blanc, un homme à la peau claire, aux cheveux foncés et à la barbe foncée, vêtu d’une chemise bleue, se tient le menton d’un air pensif.

Réfléchissez-y : en tant que spécialiste des SIG, vous ne vous contentez pas d’utiliser des logiciels. Chaque jour, vous évaluez la qualité et la pertinence des données d’entrée, mettez à profit votre expertise géographique et interprétez les résultats.

Le développeur SIG avisé doit donc être à la fois programmeur et esprit critique. Laissez l’IA rédiger, mais ne la laissez pas décider. Examinez chaque ligne de code. Vérifiez chaque donnée d’entrée. Validez chaque résultat. Confirmez les systèmes de coordonnées et les transformations. Mettez à l’épreuve les cas limites : entités vides, géométries multiparties, franchissement de l’antiméridien, unités mixtes, attributs manquants, autorisations inattendues et chemins d’accès invalides. Consignez ce qui s’est produit. Gérez les erreurs de façon réfléchie. Protégez les renseignements sensibles. Passez les dépendances en revue. Exécutez d’abord le code dans un environnement sécurisé, jamais directement sur les données de production ni sur des données dont le niveau de sensibilité n’a pas été évalué.

« Être ou ne pas être », se demande Hamlet. Dans notre cas, la question devient aussi : « Faire ou ne pas faire ».

La tragédie d’Hamlet ne réside pas dans sa réflexion, mais dans son incapacité à agir. Les développeurs SIG qui rejettent complètement l’IA risquent de connaître un sort semblable, pendant que d’autres automatisent les contrôles de la qualité, génèrent des cas de test, documentent les flux de travaux et réalisent rapidement des prototypes de manière responsable. Bien utilisée, l’IA n’est pas un roi usurpateur, mais un écuyer. Elle prend en charge les tâches répétitives, propose d’autres approches et favorise l’apprentissage, tandis que le développeur demeure le seul maître de ses intentions, des faits, de l’éthique et de la réalité géospatiale.

Alors, quelle est la réponse? Oui à l’IA, mais pas à l’IA seule. Servez-vous-en pour explorer différentes approches, ébaucher des scripts, expliquer des fonctions inconnues, générer des cas de test et mettre en lumière les points de défaillance possibles. Ne vous demandez pas seulement : « Quel code devrais-je exécuter? », mais aussi : « Pourquoi ce code, pour ces données, dans ce système de coordonnées, sous ces contraintes et avec quels risques? » L’IA peut rédiger la première version si elle le souhaite, mais assurez-vous que la version définitive porte votre signature.

Au bout du compte, la véritable question n’est pas de savoir si l’IA écrira du code SIG. C’est déjà le cas. La question plus fondamentale est de savoir si les spécialistes des SIG resteront les auteurs du raisonnement géospatial ou deviendront des fantômes, condamnés à hanter des chaînes de traitement automatisées qu’ils ne comprennent plus. Car, en SIG comme au Danemark, quelque chose se décompose lorsque le pouvoir dépasse la compréhension. L’équilibre, la rigueur et le jugement font toute la différence entre l’automatisation et l’abdication, entre la tragédie et la maîtrise.

Vous souhaitez approfondir vos capacités de raisonnement géospatial et automatiser des processus dans ArcGIS tout en conservant la maîtrise de vos décisions? Découvrez les formations connexes :

Ce billet a été écrit en anglais par Andé Piasta et peut être consulté ici.