Discussion :

[tmtisfree]

… sur sa notion si particulière de « service public ».

Le terme « public » vise ici plus particulièrement mais pas nécessairement
les développeurs Web utilisateurs des API JS de l'IGN, qui vont des codeurs
du dimanche comme moi aux experts/pros.

L'IGN est considérée en tant qu'institution publique.


Introduction et contexte
==================
Ces lignes ont été écrites suite à la panne générale des services de l'IGN
le 5 février dernier, et à la découverte de l'annonce de la suppression
prochaine de l'API JS en cours.

Ces 2 évènements ont été la goutte d'eau fatidique, bien que les points
principaux abordés dans ce message perdurent depuis des années,
tout au moins dans la tête de ce rédacteur.

Note : je passe sans vergogne de la 1ère à la 3/4ème personne.


Présentation
=========
Mon application cartographique Web basée sur l'API v2 est développée depuis
~2010 autant pour m'aider dans le suivi des informations liées à mes parcelles
(je suis agriculteur) que pour mon éducation personnelle à vouloir bâtir seul une
infrastructure et des applications Web fonctionnelles avec des outils (vaguement)
maîtrisés sur le tas (Apache/PHP/MySQL/GeoServer/HTML/JS/CSS etc.).

Par exemple en ce moment, elle me sert à modéliser des échanges de parcelles
avec rapprochement et sommation automatique des superficies, etc. pour éviter
un remembrement (qui dure près d'une décennie, on est en France).


Argumentation
==========
Comme le temps du lecteur est précieux, elle sera concise en 3 ou 4 points mais
quand même assez longue car il faut bien justifier ses dires : pour faire simple,


les API et les services IGN ou le bon, le moyen et le mauvais.


1/ La technique
---------------
En résumé : le très bon et propre.

Les API (la v2) sont bien pensées, le code agréable à lire et documenté, le résultat
époustouflant en terme de services rendus (comparé à mon niveau), les bugs
sont pris en charge (du moins quand l'API était maintenue) et les réponses
aux questions posées sont (étaient) diligemment fournies, aussi bien dans ce forum
que par courriel.

Sincèrement un grand merci pour tous les exemples, bouts de codes et réponses
aux questions parfois idiotes, le tout délivré avec professionnalisme !


2/ La disponibilité
----------------
En résumé : le moyen.

Un des points faibles récurrents de l'IGN : comment le site Web principal de
l'IGN et ses services normalement accessibles 24h/24 par pléthore
d'utilisateurs peuvent très régulièrement disparaître de la planète
Web sans que cela ne change depuis des années reste un insondable mystère.

La consultation de l'historique de ce forum montre des incidents réguliers,
des configurations ratées, des trucs qui (s)ont changés, d'autres modifiés
ou renommés, voire supprimés sans informations ou considérations pour les
conséquences etc.

Il n'y a quand même pas que des stagiaires à l'IGN ?

La page « Disponibilité » sur Géoservices est rigolote : l'IGN ne s'engage
en rien sur les chiffres avancés et reconnaît avec humour que l'hypothèse
pourrait exister que le niveau de service qu'il prétend assurer n'existe en
fait pas -- le public le subit très régulièrement -- et qu'il est donc purement
théorique (marketing).

Clairement il y a zéro politique de qualité de service en place : l'IGN
se contente de pourcentages tabulés, mais sinon navigue à vue et croise
les doigts. Ou s'en fiche. Je ne sais pas ce qui est le plus dérangeant.

48 heures indisponibles les 5 et 6 février dernier, ça fait vraiment amateur.

Mon propre serveur a été arrêté moins longtemps l'année dernière…

Pour comparer, parce qu'il faut bien une référence, je suis client des
services Amazon depuis plus longtemps qu'utilisateur des services IGN
et je ne me rappelle pas une seule panne ou incident où je n'ai pas
pu payer immédiatement et obtenir les biens/services commandés.

Chez IGN, les pannes/incidents/pertes de droits/etc. sont garantis tous les mois.

J'en suis arrivé au point que j'ai dû installer GeoServer en local avec
des Shapefiles, des TIFF et autres formats exotiques téléchargés depuis l'IGN
(quand ça fonctionne, mais merci à l'ouverture des données) pour suppléer
les déficiences de service.


J'entends bien que rien n'est parfait, que le Français n'est qu'un râleur
impénitent, que personne n'a envie de travailler le WE, soit, mais enfin !
un minimum de veille pour une institution qui se prétend de
dimension internationale serait pertinent sinon requis.


Sans compter la satisfaction des clients/utilisateurs… d'où le point suivant.


3/ La stabilité
-------------
En résumé : de mauvais à médiocre.

La stabilité et mise la disposition à long terme des API et services pourtant
financés avec de l'argent public et qui constituent donc des actifs avec
une valeur (au moins en terme de travail fourni) sont des stratégies inconnues
chez -- et peut-être même délibérément refusées par -- l'IGN.


Pour des raisons qui échappent à l'entendement du développeur Web
et/ou utilisateur final des API et des services et pour qui ces notions sont
capitales -- d'autant que l'existence de ces derniers n'est justifiée et donc
conditionnée que par leur utilisation par ces premiers --, ils sont pourtant
régulièrement « dépréciés » (le vocable euphémistiquement employé pour
indiquer oblitérés, éradiqués, décimés, génocidés, etc.) et in fine
supprimés sans aucune consultation préalable.

On est mis devant le fait accompli et ce n'est pas les délais de prévenance
ridicules qui sont proposés/annoncés qui modifient la donne.


Rappelons à l'IGN que le développeur/utilisateur des API/services IGN a
pour objectif principal de fabriquer de nouveaux usages pour lui-même ou pour d'autres,
pas d'être contraint à devoir constamment recoder ses applications pour suivre
la course sans fin des nouvelles API qui seront immanquablement rendues obsolètes
et supprimées à terme !


C'est un peu comme si l'administration fiscale décidait de supprimer le
papier sous prétexte d'informatisation inéluctable.

Que deviendraient les personnes qui pour une raison ou une autre tout
à fait valable ne sont pas informatisées ?


Ou que les développeurs du langage JavaScript décidaient unilatéralement
de supprimer « var » des spécifications sous prétexte que « const »
existe !?

100 % des sites Web disparaîtraient de la toile du jour au lendemain.


C'est pourtant ce que fait régulièrement l'IGN avec ses API !!!

L'IGN, tel un poulet sans tête, est complètement imperméable et indifférent
au fait que le but d'un utilisateur de ses API/services est précisément de
pouvoir les utiliser dans le temps, pas de le passer à leur courir après !


Le public et développeur Web se fiche pas mal de savoir si la politique
interne d'oblitération des API existantes par l'IGN est seulement
décidée pour occuper son personnel afin justifier son existence, qui, du point
de vue du présent rédacteur face à l'évolution des service depuis 2010, ne
s'apparente qu'à réinventer régulièrement la roue.

En effet les protocoles et standards sous-jacents sur lesquels sont basés
les API/services évoluent beaucoup, beaucoup, plus lentement et le but
des API/services IGN reste fondamentalement inchangé : envoyer des images
et des données.


D'autant qu'il n'y a aucune raison technique qui s'oppose à conserver
les API/services existants : leur maintenance est minime puisqu'ils sont
déjà fonctionnels.

Ce n'est juste qu'une question de volonté inexistante pour le moment :
le code utilisateur doit s'adapter ou mourir. Même le privé est moins exigeant
et supporte ses créations plus longtemps.


Ce n'est pas le développement de passerelles pour conserver la compatibilité
qui devraient poser des problèmes insurmontables aussi bien techniques que
financiers vu le rythme des éradications.


Ce qui amène naturellement au 4ème et dernier point bonus :


4/ Le pire
---------

En plus de l'enterrement régulier des API, ce qui est particulièrement
choquant (et fascinant d'un point de vue sociologique) est la disparition
systématique, de toute la documentation et des exemples relatifs
aux API obsolètes/supprimées.

Une recherche approfondie et de longue date sur le Web démontre
qu'une purge délibérée quasi totale a été opérée pour la V2 : un tel
systématisme cela fait penser à cette fameuse photo N&B où des
personnages impopulaire pour le leader en place disparaissent
à mesure que l'Histoire avance…


Incompréhensible, inadmissible et juste lamentable.


Qu'est-ce qui peut bien justifier le non-maintien en ligne de
quelques Go d'informations statiques sinon la claire intention
et volonté de forcer le public/développeur à ne plus les utiliser pour
le contraindre à basculer vers les (supposées) nouveautés ?


Cette pratique de forçage renverse totalement la notion même de « service public »
exemplifiant au passage la théorie des choix publics :

L'IGN EST UNE INSTITUTION PUBLIQUE AU SERVICE DU PUBLIC.

LE PUBLIC N'A PAS À SE METTRE AU SERVICE DE L'IGN.

(ou d'une de ses API particulière)


D'autant qu'il est facile de justifier la question précédente :

l'auteur utilise encore l'API v2 qui toujours fonctionnelle à ~95 %
avec un minimum de modification à la hauteur de ses (maigres) moyens.

Les 5 % non fonctionnels (secondaires en terme d'utilité/usage) sont dus aux
liens vers les propres pages Web de documentation supprimées chez l'IGN !



Prescription
=========

En décidant unilatéralement de supprimer des biens publics (le fait
qu'API, services et documentation soient immatériels est sans
rapport : on peut quand même estimer leur valeur), l'IGN faillit
à sa mission et gaspille l'argent et le temps du public et du développeur
en particulier qu'il force à s'adapter à des services affichés comme
nouveaux mais qui ne font pour l'essentiel que reprendre les anciens,
dûment éradiqués, sous une forme certes différente mais
identiques sur le fond puisqu'ils représentent par définition une des
missions de l'IGN.


Dès lors.

Il est demandé à ce que les API/services/documentation existants
et généralement fonctionnels (si on fait abstraction du manque
de veille) le restent à l'avenir parce que c'est dans

***l'intérêt du public***,

qui, il faut le répéter, ne doit pas devenir otage d'une course
à l'échalote technique dont les motifs lui échappent.


Il est aussi demandé à ce que l'accès à la documentation des API et
services précédents soient intégralement rétablis et accessibles : au
moins d'un point de vue historique, le public a intérêt (et est en droit)
de connaître et apprécier l'évolution du travail réalisé par les
équipes de l'IGN (qu'il a financé, répétons-le).

À ce stade il n'est demandé aucun support sur ces API encore
fonctionnelles autres que la conservation de la compatibilité avec les évolutions
techniques envisagées, ce pour les raisons légitimement invoquées plus haut,
et la remise à disposition et conservation des documentations complètes.

Bien entendu, l'IGN reste parfaitement libre et maître de fabriquer
tous les API et services futurs qu'il pourrait décider.

Si pour une obscure raison l'IGN refusait, l'auteur suggère de mettre ces
informations à disposition de la communauté des développeurs qui la
prendra en charge, elle. Ou au pire d'en faire un Zip sur son Github.


Conclusion personnelle
================

Le rédacteur/utilisateur se rappelle qu'à l'époque du passage de la v2
à la v3 circa 2015, il avait longuement réfléchi à déterminer un seul
intérêt à migrer et n'en avait trouvé aucun, pressentant que la lenteur des
évolutions dans les protocoles, standards et infrastructure devait être
considérée comme étant plus pertinente. QED.

(Indiquons ici que ma propre lenteur à développer, combinée
à une révulsion naturelle à dupliquer le travail en recodant du code
parfaitement fonctionnel par ailleurs ont aussi été des facteurs décisifs.)

Néanmoins une prochaine éradication de l'API en cours est annoncée,
ce qui va finalement anéantir tout l'intérêt des services IGN pour
cause dévolution (!) incompatible avec l'existant, qui représente non
seulement un investissement passé conséquent, mais surtout futur
inconséquent, lui.


Donc pour lutter contre l'obsolescence programmée des API/services
IGN fonctionnels (hors pannes et incidents bien pardonnables à ce stade),
j'envisage la complète migration locale des services primaires (couches)
et suppression pure et simple des services secondaires (calculs, LUS, etc.).


Signé,

Un utilisateur (ind)IGN(é) et déçu mais futurement autonome.

[saxrub]

Bonjour Tntisfree, bonjour l'IGN.

Comme Tnfisfree, j'utilise les services API de l'IGN depuis 2010.

Si je suis passé en V3 et me suis adapté aux "services gratuits" (mais à quel coût ; on nous annonce qu'il va falloir s'adapter plus d'un an à l'avance, mais les nouveaux services ne sont opérationnels qu'un mois avant le big bang), je partage le ressenti de Tbfisfree sur la disponibilité et la performance des services IGN.

- disponibilité : comme le dit TNfisfree, au moins une panne par mois depuis août 2020 ; ce n'est pas l'IGN qui passe pour un charlot quand les services de mes WEB et applications mobiles ne fonctionnent plus, c'est moi !

- performance : là où il y a quelques années, mon robot web permettait de résoudre 100 géoréférencements inverses en une minute, la même page a dû être calibrée pour n'en traiter que 20 en une minutes. Je suis un gros consommateur de géoréférencement inverse et la BETA 2 qui est très performante n'arrive toujours pas à être mise en production. Aucune instance de l'IGN ne se prononce sur la date de mise en production. Des demandes de modification de la BETA 2 ont été émises par des utilisateurs du forum, en particulier, l'augmentation du rayon de recherche !

Je partage aussi l'aspect régressif de la documentation ; y a en partout, certaines se contredisant, certaines disparaissent purement et simplement.

Bref, pour moi, les services fournis par l'IGN sont indispensables et incontournables mais il est grand temps que la qualité de ces services redeviennent une priorité pour l'IGN.

[xavier_dmz]

Bonjour tmtisfree,

Avant toute chose quelques petites précautions à prendre en compte sur ce que je vais dire :

• Bien que je sois développeur pour l'IGN au sein de l'écosystème géoportail, je ne suis pas impliqué sur les API javascript d'accès aux flux mentionnées ici sous les noms "API v2" et "API v3". Je ne peux donc pas répondre sur le fond sur les décisions prises ou pas prises sur ce projet.
• En revanche je suis développeur au sein de la même équipe, et j'ai en tête certaines grandes lignes des contraintes de nos projets, liées au projet géoportail dans son ensemble.
• Je vais ici parler de ma propre initiative, sans relecture de la part de notre équipe, et encore moins de la part des services de relations publiques de l'IGN. (Mais avec les limitations légales qui s'imposent à mon discours.)

Quelques remarques générales me viennent en tête sur le contenu de votre lettre ouverte, que je vais énoncer ici avant de répondre à ce sur quoi j'estime pouvoir apporter quelques chose :

• Lors de la préparation au concours dans la fonction publique, on peut apprendre que le mot "public" l'expression "service public" ne fait pas référence aux citoyens, mais à l'état. Certes, l'état devrait être au service des citoyens, dont indirectement cela place les services publics au service des citoyens, mais ce n'est pas le sens de l'expression. Si l'état n'est pas aux services des citoyens dans leur ensemble, c'est à dire du peuple, c'est un problème dans une république ou une démocratie.
• L'expression "obsolescence programmée" a un sens assez fort, et je ne suis pas sûr qu'il est adapté ici. À moins que des mécanismes technologiques, logistiques, inclus délibérement dans l'API v2 dans le but spécifique de la rendre inutilisabl passé un date arbitraire ou son remplacement ? (Si je comprends bien le sens de l'expression.) Rien ne l'indique.
• La comparaison historique d'une gestion de techologies à des assassinats orchestrés par une célèbre dictature est déplacée et insultante. Elle n'a pas sa place ici. Du tout.
• Le site www.ign.fr et les services web de l'écosytème géoportail sont indépendants, bien que tout deux gérés par l'IGN.
• Les agents de l'IGN actifs ici sont principalement des développeurs de l'écosystème géoportail et des membres d'équipes de support. Votre lettre publique ne s'adresse donc pas aux bonnes personnes. Notre influence dans les décisions de l'IGN en tant qu'organistation existent, mais est limitée.

Pour le résumé de ce que j'ai compris dans votre message, en retirant les attaques et le bruit :

• 48h d'indisponibilité des services, c'est beaucoup trop.
• Vous voudriez plus de garanties sur la disponiblité des services. (À préciser)
• En particulier, un support et une veille officielles en heures non ouvrées.
• Supprimer à l'accès aux anciennes versions d'un outil mis à disposition publique, de son code source, et de sa documentation, c'est inacceptable, en particulier par un organisme financé par les fonds publics.
• Il faudrait donc rétablir l'accès à ces éléments supprimés.
• Mais aussi ne pas récidiver, et donc garantir la pérennité de l'existant et du futur.
• Si en plus nous assurions un support continu et à durée indéfinie sur les anciens outils, ce serait encore mieux.
• Ou à défaut confier la suite à la communauté.
• (Désolé pour le côté caricatural du point suivant, mais c'est cohérent avec votre propre ton.) Les changements de versions avec rupture ont des conséquences catastrophiques.

Pouvez-vous vérifier et confirmer que j'ai bien compris et rien oublié ? (En excluant les attaques, les métaphores douteuses, et les affirmations péremptoires, merci.)
A noter que, dramtisation mise à part, je trouve qu'il est pertinent d'aborder ces sujets.




Pour la partie point par point, super longue, et par moment un peu salée :

… sur sa notion si particulière de « service public ».

Le terme « public » vise ici plus particulièrement mais pas nécessairement
les développeurs Web utilisateurs des API JS de l'IGN, qui vont des codeurs
du dimanche comme moi aux experts/pros.

L'IGN est considérée en tant qu'institution publique.

Ce point est abordé dans mes remarques générales.

Introduction et contexte
==================
Ces lignes ont été écrites suite à la panne générale des services de l'IGN
le 5 février dernier, et à la découverte de l'annonce de la suppression
prochaine de l'API JS en cours.

Ces 2 évènements ont été la goutte d'eau fatidique, bien que les points
principaux abordés dans ce message perdurent depuis des années,
tout au moins dans la tête de ce rédacteur.

Note : je passe sans vergogne de la 1ère à la 3/4ème personne.

La panne générale des services décrites provient de problèmes chez notre hébergeur. Nous n'hébergeons pas nous même notre infrastructure au sein de l'IGN.
Les changements annoncés sur l'API sont liés à des changements futurs de tout ce à quoi ces API se branchent.

1/ La technique
---------------
En résumé : le très bon et propre.

Les API (la v2) sont bien pensées, le code agréable à lire et documenté, le résultat
époustouflant en terme de services rendus (comparé à mon niveau), les bugs
sont pris en charge (du moins quand l'API était maintenue) et les réponses
aux questions posées sont (étaient) diligemment fournies, aussi bien dans ce forum
que par courriel.

Sincèrement un grand merci pour tous les exemples, bouts de codes et réponses
aux questions parfois idiotes, le tout délivré avec professionnalisme !

Merci pour les personnes impliquées. (Rappel: pas moi)

2/ La disponibilité
----------------
En résumé : le moyen.

Un des points faibles récurrents de l'IGN : comment le site Web principal de
l'IGN et ses services normalement accessibles 24h/24 par pléthore
d'utilisateurs peuvent très régulièrement disparaître de la planète
Web sans que cela ne change depuis des années reste un insondable mystère.

La consultation de l'historique de ce forum montre des incidents réguliers,
des configurations ratées, des trucs qui (s)ont changés, d'autres modifiés
ou renommés, voire supprimés sans informations ou considérations pour les
conséquences etc.

Nous sommes autant victimes des incidents que vous, pour information.

Il n'y a quand même pas que des stagiaires à l'IGN ?

Attaque inappropriée. C'est insultant tant pour nous que pour les stagiaires, toutes professions confondues. ("stagiaire" != "boulet")

La page « Disponibilité » sur Géoservices est rigolote : l'IGN ne s'engage
en rien sur les chiffres avancés et reconnaît avec humour que l'hypothèse
pourrait exister que le niveau de service qu'il prétend assurer n'existe en
fait pas -- le public le subit très régulièrement -- et qu'il est donc purement
théorique (marketing).

Pour les curieux, la page incriminée : https://geoservices.ign.fr/documenta.../disponibilite
Et le passage de texte qui indique les engagements :

L’IGN s’engage à assurer les niveaux de disponibilité figurant ci-dessous. Dans l’hypothèse où un niveau de service ne serait pas atteint, l’IGN s’engage à limiter au maximum l’indisponibilité, et ce, indépendamment du fait qu’il soit ou non fait application de compensations.

Clairement il y a zéro politique de qualité de service en place : l'IGN
se contente de pourcentages tabulés, mais sinon navigue à vue et croise
les doigts. Ou s'en fiche. Je ne sais pas ce qui est le plus dérangeant.

Par curiosité (je n'ai aucune influence ici, je le rappelle) : à quoi vous attendez-vous exactement comme engagement, en justifiant ?

48 heures indisponibles les 5 et 6 février dernier, ça fait vraiment amateur.

Et bizarrement peu de professionnels sont à l'abri ? Comme dit, nous ne sommes pas hébergeurs. C'est comme si je disais que l'indisponibilité de certaines fonctionnalités de votre site à cause de nos services HS était de l'amateurisme de votre part. Là encore, nos équipes ont fait ce qu'elles pouvaient.

Mon propre serveur a été arrêté moins longtemps l'année dernière…

En quoi cette comparaison est-elle pertinente ? Je ne pense pas que votre serveur est opéré dans des conditions comparables.

Pour comparer, parce qu'il faut bien une référence, je suis client des
services Amazon depuis plus longtemps qu'utilisateur des services IGN
et je ne me rappelle pas une seule panne ou incident où je n'ai pas
pu payer immédiatement et obtenir les biens/services commandés.

Chez IGN, les pannes/incidents/pertes de droits/etc. sont garantis tous les mois.

Vous comparez le plus gros, riche et puissant fournisseurs de services web (et hébergeur) du monde à un lot de services web qui représentent un petite partie des responsabilités d'un établissement public national dédié à l'information géographique. Là encore, quelle est la pertinence ?

J'en suis arrivé au point que j'ai dû installer GeoServer en local avec
des Shapefiles, des TIFF et autres formats exotiques téléchargés depuis l'IGN
(quand ça fonctionne, mais merci à l'ouverture des données) pour suppléer
les déficiences de service.

J'en suis désolé. Je le rappel, nous ne sommes pas plus heureux que vous des incidents que nous subissons. aussi bien quand nous en sommes responsables que quand nous en sommes nous-même simples victimes.

J'entends bien que rien n'est parfait, que le Français n'est qu'un râleur
impénitent, que personne n'a envie de travailler le WE, soit, mais enfin !

Le travail le week-end ce n'est pas juste une histoire d'envie. Il y a un cadre légal à respecter.
Mais pour information, des collègues ont bien travaillé le week-end, en dehors de tout cadre, pour résoudre le problème. (Mais ils avaient des priorités plus grandes que vous contacter, à savoir essayer de résoudre le problème de fond.)

un minimum de veille pour une institution qui se prétend de
dimension internationale serait pertinent sinon requis.

Pour le coup, il y a bien eu une réaction rapide le jour même, mais sans effet visible pour vous, et sans moyens car hors des cadres définis. C'est donc une remontée pertinente à faire de manière plus constructive par les canaux appropriés.

Sans compter la satisfaction des clients/utilisateurs… d'où le point suivant.


3/ La stabilité
-------------
En résumé : de mauvais à médiocre.

La stabilité et mise la disposition à long terme des API et services pourtant
financés avec de l'argent public et qui constituent donc des actifs avec
une valeur (au moins en terme de travail fourni) sont des stratégies inconnues
chez -- et peut-être même délibérément refusées par -- l'IGN.


Pour des raisons qui échappent à l'entendement du développeur Web
et/ou utilisateur final des API et des services et pour qui ces notions sont
capitales -- d'autant que l'existence de ces derniers n'est justifiée et donc
conditionnée que par leur utilisation par ces premiers --, ils sont pourtant
régulièrement « dépréciés » (le vocable euphémistiquement employé pour
indiquer oblitérés, éradiqués, décimés, génocidés, etc.) et in fine
supprimés sans aucune consultation préalable.

On est mis devant le fait accompli et ce n'est pas les délais de prévenance
ridicules qui sont proposés/annoncés qui modifient la donne.

Je ne suis pas d'accord avec votre méthode d'expression, mais je suis d'accord sur les problèmes que ça pose, étant moi-même développeur. Cependant, si les raisons échappent à votre entendement, elles n'échappent pas forcément à celui de développeurs travaillant pour une grosse structure ou avec divers prestataires. La complexité des structures qui gèrent un projet a des imapcts notables sur la gestion de ces projets. Ça n'enlève rien au problème, mais ce n'est pas trivial à résoudre.

Rappelons à l'IGN que le développeur/utilisateur des API/services IGN a
pour objectif principal de fabriquer de nouveaux usages pour lui-même ou pour d'autres,
pas d'être contraint à devoir constamment recoder ses applications pour suivre
la course sans fin des nouvelles API qui seront immanquablement rendues obsolètes
et supprimées à terme !

Rappelons que les agents de l'IGN ici présent ne sont pas l'IGN, mais des agents de l'IGN. Et pour information, nous sommes nous-même utilisateurs de ces mêmes services web, dont le site géoportail est un consommateur.

C'est un peu comme si l'administration fiscale décidait de supprimer le
papier sous prétexte d'informatisation inéluctable.

Que deviendraient les personnes qui pour une raison ou une autre tout
à fait valable ne sont pas informatisées ?

Je suis d'accord sur l'impact de cette informatisation à outrance sans donner aux citoyens les moyens approriés, mais je ne vois pas le rapport avec les API du géoportail. Lors de nos changements technologiques avec rupture nous passons d'une techno à une autre similaire, qui demandent le même niveau de compétence pour être utilisées. comapraison plus pertinente : c'est plutôt comme si votre employeur changeait un de vos outils de travail par un outil concurrent, par exemple de MS Word à LibreOffice Writer ou vice-versa, à cause d'un changement de prestataire suite au renouvellement d'un marché public. Oui, il y a une problématique d'accompagnement des utilisateurs à gérer, mais ce n'est en rien comparable à l'abandon de toute une partie de la population par l'administration.

Ou que les développeurs du langage JavaScript décidaient unilatéralement
de supprimer « var » des spécifications sous prétexte que « const »
existe !?

Non.

100 % des sites Web disparaîtraient de la toile du jour au lendemain.

Non plus.
(Et pour cette comparaison avec une rupture sur un langage de programmation populaire, voyez python, qui fonctionne encore malgré ses guerres de chappelles python 2 VS python 3.)

C'est pourtant ce que fait régulièrement l'IGN avec ses API !!!

<sarcasme> Tous les jours même ! </sarcasme>
Plus sérieusement, nous avons effectivement besoin de nous améliorer sur certains points. Ce n'est cependant pas ainsi que vous y contribuerez.

L'IGN, tel un poulet sans tête, est complètement imperméable et indifférent
au fait que le but d'un utilisateur de ses API/services est précisément de
pouvoir les utiliser dans le temps, pas de le passer à leur courir après !

Non.

Le public et développeur Web se fiche pas mal de savoir si la politique
interne d'oblitération des API existantes par l'IGN est seulement
décidée pour occuper son personnel afin justifier son existence, qui, du point
de vue du présent rédacteur face à l'évolution des service depuis 2010, ne
s'apparente qu'à réinventer régulièrement la roue.

Et heureusement qu'il s'en fiche, parce que votre accusation est infondée et très probablement fausse. Enfin, j'espère.

En effet les protocoles et standards sous-jacents sur lesquels sont basés
les API/services évoluent beaucoup, beaucoup, plus lentement et le but
des API/services IGN reste fondamentalement inchangé : envoyer des images
et des données.

"Plus lentement", vraiment ? Et dire que nous arrivons malgré tout à prendre du retard.
Certaines de nos dépendances évoluent assez vite par rapport à nos projets que nous sommes nous mêmes confrontés à des abandons de support de nos dépendances. Devrais-je publiquement incendier GDAL pour les efforts de traduction de Perl 5 vers Python 3 pour un de nos outils, d'après vous ?

D'autant qu'il n'y a aucune raison technique qui s'oppose à conserver
les API/services existants : leur maintenance est minime puisqu'ils sont
déjà fonctionnels.

Vous êtes bien catégorique. Pouvez-vous argumenter ?

Vous allusions répétées à la trivialité du maintien de nos outils et services me rappelle une anecdote personnelle : je ne compte plus le nombre de messages vu sur des forums, BBS, et autres moyens de communication, où quelqu'un prétend que ce qu'il n'aime pas sur un site ou un service est un problème gravissime mais trivial à résoudre et que le fait qu'il existe et ne soit pas corrigé est une preuve d'amateurisme car un collégien dans un club d'informatique ferait mieux. Essayez d'éviter ce genre piège, ça ne rend service à personne, même pas à vous.
Pour dire ça autrement : vous n'avez pas accès à tous les détails de la gestion de ces outils et services, et vous vous présentez vous-même comme un "codeur du dimanche", donc évitez d'affirmer de manière péremptoire que tout est facile, et que nous sommes des "amateurs", des "stagiaires" et des nuls.

Ce n'est juste qu'une question de volonté inexistante pour le moment :

Non.

le code utilisateur doit s'adapter ou mourir.

Il est bon de discuter de ça.
Je ne sais pas si votre accusation est vraie, mais le sujet est important.

Même le privé est moins exigeant
et supporte ses créations plus longtemps.

Cette généralisation me paraît abusive. Dans le public comme dans le privé, ou le communautaire, cela varie d'une entreprise à l'autre, d'un projet à l'autre, selon de nombreux facteurs.

Ce n'est pas le développement de passerelles pour conserver la compatibilité
qui devraient poser des problèmes insurmontables aussi bien techniques que
financiers vu le rythme des éradications.

Il faut savoir, ce rythme est très élevé ou très lent ?

Ce qui amène naturellement au 4ème et dernier point bonus :


4/ Le pire
---------

En plus de l'enterrement régulier des API, ce qui est particulièrement
choquant (et fascinant d'un point de vue sociologique) est la disparition
systématique, de toute la documentation et des exemples relatifs
aux API obsolètes/supprimées.

Forme mise à part, en effet.
Garder disponibles les vieilles versions me paraît important. (Si je ne me plante pas, l'API V3 est d'ailleur sur github, ce qui limite ce genre de situations à l'avenir.)

Une recherche approfondie et de longue date sur le Web démontre
qu'une purge délibérée quasi totale a été opérée pour la V2 : un tel
systématisme cela fait penser à cette fameuse photo N&B où des
personnages impopulaire pour le leader en place disparaissent
à mesure que l'Histoire avance…

D'après un certain M. Godwin, c'est à partir d'ici que le discours ne peut plus être constructif. Même si lui faisait référence à un autre régime tyrannique contemporain de celui que vous utilisez.
Je vais cependant continuer mon message.
Vous, en revanche, arrêtez avec ça.

Incompréhensible, inadmissible et juste lamentable.

Merci de confirmer ce que je viens de dire.

Bon, j'ai dit que j'essayais d'être constructif. Passons donc à autre chose.

Qu'est-ce qui peut bien justifier le non-maintien en ligne de
quelques Go d'informations statiques sinon la claire intention
et volonté de forcer le public/développeur à ne plus les utiliser pour
le contraindre à basculer vers les (supposées) nouveautés ?

Qu'est-ce qui vous paraîtraît une justification valable, et pas une simple excuse pour cacher une
"volonté de forcer le public/développeur à ne plus les utiliser pour
le contraindre à basculer vers les (supposées) nouveautés" ?

Cette pratique de forçage renverse totalement la notion même de « service public »

non

exemplifiant au passage la théorie des choix publics :

L'IGN EST UNE INSTITUTION PUBLIQUE AU SERVICE DU PUBLIC.

LE PUBLIC N'A PAS À SE METTRE AU SERVICE DE L'IGN.

(ou d'une de ses API particulière)

Correction :

L'IGN est une institution publique au service du secteur public, donc de l'état.
Les citoyens n'ont pas à se mettre au service d'une institution publique, donc de l'état. (sauf s'ils sont fonctionnaires, et uniquement dans le cadre de leur mission.)

Comme je l'ai déjà dit, si l'état n'est plus au service du peuple qu'il est censé représenter, c'est en effet un problème. Je ne peux pas me prononcer sur le fait qu'on soit ou non dans cette situation.
Cependant, si cette situation était avérée, le comportement d'une institution en particulier n'en serait qu'un symptôme, et taper sur les agents de cette institution n'apporterait rien de bon.

D'autant qu'il est facile de justifier la question précédente :

l'auteur utilise encore l'API v2 qui toujours fonctionnelle à ~95 %
avec un minimum de modification à la hauteur de ses (maigres) moyens.

Les 5 % non fonctionnels (secondaires en terme d'utilité/usage) sont dus aux
liens vers les propres pages Web de documentation supprimées chez l'IGN !

Cette anecdote permet de justifier de laisser l'API v2 et sa documentation à disposition, mais ne permet pas de statuer sur la trivialité de sa maintenance, ni sur les besoins d'évolution de nos outils.

Prescription
=========

En décidant unilatéralement de supprimer des biens publics (le fait
qu'API, services et documentation soient immatériels est sans
rapport : on peut quand même estimer leur valeur), l'IGN faillit
à sa mission

L'IGN a plusieurs missions. Pas sûr que l'API concernée en fasse partie, mais mes connaissances sur ce sujet sont très réduites. (Quelles sont les votres ?) Je n'ai pas le courage de lire les dernières publications officielles des objectifs et missions de l'IGN.

et gaspille l'argent et le temps du public et du développeur

Répondre à des attaques véhémentes qui noient des remontées pourtant pertinente est aussi une perte d'argent public, et de temps et d'énergie pour les développeurs qui s'en chargent.
Vous auriez pu faire une remontée plus respectueuse, plus constructive, et plus brève sans perdre en argumentation.

en particulier qu'il force à s'adapter à des services affichés comme
nouveaux mais qui ne font pour l'essentiel que reprendre les anciens, dûment éradiqués, sous une forme certes différente mais
identiques sur le fond puisqu'ils représentent par définition une des
missions de l'IGN.

C'est bizarre de tout à coup dire qu'il n'y a pas de changement dans un message de plainte sur les ruptures imposées par ces changements, non ?
Pouvez-vous décrire les changements dans l'API qui vous posent problème, pour illustrer sans formulation bizarre ?

Dès lors.

Il est demandé à ce que les API/services/documentation existants
et généralement fonctionnels (si on fait abstraction du manque
de veille) le restent à l'avenir parce que c'est dans

***l'intérêt du public***,

Ça me paraît être un élément au coeur du message, et totalement pertinent. Dommage que ce soit noyé dans des attaques contre-productives.

qui, il faut le répéter, ne doit pas devenir otage d'une course
à l'échalote technique dont les motifs lui échappent.

Euh... hein ?!?

Il est aussi demandé à ce que l'accès à la documentation des API et
services précédents soient intégralement rétablis et accessibles : au
moins d'un point de vue historique, le public a intérêt (et est en droit)
de connaître et apprécier l'évolution du travail réalisé par les
équipes de l'IGN (qu'il a financé, répétons-le).

Là encore, une remontée pertinente et importante qui aurait gagné à être mieux amenée.

À ce stade il n'est demandé aucun support sur ces API encore
fonctionnelles autres que la conservation de la compatibilité avec les évolutions
techniques envisagées, ce pour les raisons légitimement invoquées plus haut,
et la remise à disposition et conservation des documentations complètes.

De toute façon, je pense qu'assurer un support sur les anciennes versions en plus de la version actuelle serait compliqué avec nos moyens actuels. Contrairement à vos accusations, les abandons ne sont pas sans raison, et si on cherchait juste à occuper les agents, on garderait au contraire un maximum de projets (surtout s'il demandent réellement des efforts bénins).

Bien entendu, l'IGN reste parfaitement libre et maître de fabriquer
tous les API et services futurs qu'il pourrait décider.

Encore heureux ? Notez que cette "liberté" est relative. Vous savez déjà que l'IGN n'est pas un organisme indépendant, vous pouvez donc réaliser que d'autres structures peuvent définir nos objectifs, avec plus ou moins d'efficacité. (Par exemple, nos ministères de tutelle.)

Si pour une obscure raison l'IGN refusait, l'auteur suggère de mettre ces
informations à disposition de la communauté des développeurs qui la
prendra en charge, elle. Ou au pire d'en faire un Zip sur son Github.

C'est une proposition de solution technique aux problèmes soulevés.

Conclusion personnelle
================

Le rédacteur/utilisateur se rappelle qu'à l'époque du passage de la v2
à la v3 circa 2015, il avait longuement réfléchi à déterminer un seul
intérêt à migrer et n'en avait trouvé aucun, pressentant que la lenteur des
évolutions dans les protocoles, standards et infrastructure devait être
considérée comme étant plus pertinente. QED.

(Indiquons ici que ma propre lenteur à développer, combinée
à une révulsion naturelle à dupliquer le travail en recodant du code
parfaitement fonctionnel par ailleurs ont aussi été des facteurs décisifs.)

Cette réflexion n'étant fondée que sur les informations auxquelles vous aviez vous-même accès et sur vos propres compétences. Ne vous imaginez pas que les décisions prises le sont par une seule personne à l'IGN, que tout les autres agents et prestataires suivraient bêtement sans poser de questions.

Néanmoins une prochaine éradication de l'API en cours est annoncée,
ce qui va finalement anéantir tout l'intérêt des services IGN pour
cause dévolution (!) incompatible avec l'existant, qui représente non
seulement un investissement passé conséquent, mais surtout futur
inconséquent, lui.

Non, un changement de version majeure d'un outil logicielle n'est pas synonyme de fin du monde ou autre diagnostic fataliste.

Donc pour lutter contre l'obsolescence programmée des API/services
IGN fonctionnels (hors pannes et incidents bien pardonnables à ce stade),

Que dire...

j'envisage la complète migration locale des services primaires (couches)
et suppression pure et simple des services secondaires (calculs, LUS, etc.).


Signé,

Un utilisateur (ind)IGN(é) et déçu mais futurement autonome.

En tant qu'agent de l'IGN : attention aux coditions d'utilisation imposées par les licences et autres droits d'auteur.

Ensuite, c'est le technicien qui parle :

Si vous avez besoin de toutes les couches de données, même uniquement sur un seul service raster comme le WMTS, attention à l'espace de stockage.
De plus, si vous avez un grand nobre d'utilisateurs, vous allez vite vous rendre compte que la problématique n'est pas triviale, et que les mêmes efforts seraient peut-être plus productifs sur une migration de version.
Je ne remets pas encause ici le bien fondé des remarques que j'ai moi-même qualifiées de pertinentes plus haut. je compare juste deux scénarios basés sur l'état actuel : migre vers de nouvelles API et tout refaire à la main en local.

[xavier_dmz]

Bonjour saxrub,

(Là encore, personne ne m'a relu avant envoi, hein.)

Je passe les paragraphes sur lesquels je n'ai rien à dire de pertinent.

- disponibilité : comme le dit TNfisfree, au moins une panne par mois depuis août 2020 ; ce n'est pas l'IGN qui passe pour un charlot quand les services de mes WEB et applications mobiles ne fonctionnent plus, c'est moi !

Certes, remplacez, pour certains incidents, "l'IGN" par "les prestaires de l'IGN" et "moi" par "lIGN", et vous verrez que nous connaissons aussi ce problème. Ça ne nous exempt pas de responsabilité pour autant, certes, mais je comprends votre position car nous la vivons aussi, comme toute autre entreprise dépendant de service externes.

- performance : là où il y a quelques années, mon robot web permettait de résoudre 100 géoréférencements inverses en une minute, la même page a dû être calibrée pour n'en traiter que 20 en une minutes. Je suis un gros consommateur de géoréférencement inverse et la BETA 2 qui est très performante n'arrive toujours pas à être mise en production. Aucune instance de l'IGN ne se prononce sur la date de mise en production. Des demandes de modification de la BETA 2 ont été émises par des utilisateurs du forum, en particulier, l'augmentation du rayon de recherche !

Qu'appelez vous "mise en production". Le retrait du mot "bêta" ? La correction de tous les problèmes remontés par les utilisateurs ? Ou la mise à disposition sur les flux normaux de nos services de production, donc normalement leur emplacement définitif jusqu'au prochain changement de marché ?
Ce nouveau service de géocodage et d'autocomplétion est disponible sur les flux publics, et utilisé par le site géoportail. De mon point de vue, il est déjà en production, quoi que perfectibe.
Il y a encore des correctifs identifiés à apporter, dont certains, sinon tous, sont déjà prêts et en attente de déploiement. (Ce n'est pas si simple que ça peut le sembler depuis l'extérieur, pour un écosytème si tentaculaire.) Pour le reste, les demandes ont été reçues par notre équipe.
Maintenant, notre équipe ne peut pas pas maîtriser toutes les contraintes de déploiement, sur lesquelles je ne m'étalerai pas.

Je partage aussi l'aspect régressif de la documentation ; y a en partout, certaines se contredisant, certaines disparaissent purement et simplement.

Vaste sujet.
Il y a probablement des améliorations à apporter à notre documentation, et je suis personnellement d'accord avec le maintien de la documentation des anciennes versions d'outils, au moins sous forme d'archives.
Pour les services, par contre, je ne suis pas sûr de l'intérêt technique de maintenir à disposition des documentations qui ne correspondraient plus à l'état présent des services. (J'en vois les intérêts historiques et de tracabilité.)
Quelles seraient donc les finalités, d'un point de vue technique, de la documentation des services disparus ? Permettre d'émuler ces services sur un réseau privé ?