Il y a beaucoup de faux positifs (bâches, reflets, panneaux solaires, places de parking handicapé, etc) ;
Si tu lis le forum OSM en lien plus haut, ce développeur estime à 5% de faux-positif. Dans tous les cas, un tel système est une aide. Le traitement réel doit passer par des humains de toutes façons, donc les faux-positifs, tant qu'ils ne sont pas de l'ordre de 50% (là, c'est que le système est cassé et n'a aucun intérêt), on s'en fout.
Le problème des faux-positifs, c'est quand un tel système de détection est utilisé seul pour prendre une décision. Et dans les décisions de type administratives/légales, les conséquences peuvent être graves. On a déjà vu ce genre de problème avec des gens arrêtés sur la seule base de reconnaissance facile défaillante, notamment pas mal aux US où ce genre de pratiques semble devenir courantes (voir ce cas, ou encore ce cas ou celui-là ou... en fait il semble y en avoir tellement depuis des années que c'en est ahurissant!).
Forcément personne n'aimerait avoir une amende pour une piscine non-déclarée alors... que cette personne n'a même pas de piscine (ils auraient peut-être étalé une bâche et ça a été pris pour tel ou autre faux-positif)! C'est pas pareil que se faire arrêter, mais avec les prises de tête administratives, notamment pour faire admettre les erreurs, le temps perdu, le stress... ce serait aussi très moche pour une famille de subir cela (d'autant plus pour des familles plus modestes pour lesquels ce genre de problèmes peut devenir dramatique).
Donc bon quel que soit le système, il faut une vrai vérification par un vrai humain, d'abord visuelle (pour détecter les faux-positifs évidents avec vérification sur écran) puis manuelle, sur place (pour les cas plus douteux: genre le coup de la bâche: il y a peut-être vraiment une piscine dessous!). Et ce, que le prestataire de développement soit CapGemini ou un geek dans son coin.
Ah et croire que CapGemini soit capable de faire cela sans aucun faux-positif aussi serait totalement absurde et ne ferait que montrer une incompréhension totale de la technologie. Comme toute technologie, il faut juste l'utiliser responsablement, ce qui inclue de la comprendre ainsi que ses limites.
Il y a beaucoup de faux négatifs (piscines de formes ou couleurs bizarres, effets des caractéristiques des images satellites, piscines partiellement ou totalement couvertes ;
Ça n'est pas pire que la situation actuelle dans le contexte de l'administration qui cherche à retrouver les gens qui ne déclarent pas les piscines. Autant les faux-positifs sont effectivement un réel danger (pour les citoyens honnêtes pris dans les filets de la technologie mal comprise par les administrations, donc pour une société juste dans son ensemble), autant les faux-négatifs ne changent pas grand chose. Les administrations doivent simplement continuer à faire un travail manuel pour trouver des piscines autrement, et ne pas compter exclusivement sur la sacro-sainte IA pour ces cas qui passent entre les mailles du filet.
Dans tous les cas, en soi, les faux négatifs sont beaucoup moins un problème, n'empirent pas la situation et ne créent aucun cas d'injustice comme pourraient le faire les faux positifs (qui effectivement doivent vraiment être regardés de près et pris en compte avec un grosse priorité dans le projet).
Le croisement avec les données cadastrales (pour savoir qui n’a pas déclaré, dans ce cas) n’est pas trivial (notamment à cause desdites données) ;
Ce qui peut ne pas être trivial est éventuellement le côté administratif, si les données cadastrales ne sont pas déjà proprement enregistrées, avec des API utilisables, et bien partagées entre administration. Que ce soit CapGemini ou un autre ne change pas la donne.
Mais si les infos sont déjà accessibles, techniquement il n'y a vraiment aucun problème à faire des rapprochements entre piscines détectées sur des images satellitaire et données cadastrales sur l'emplacement de piscines déclarées.
C'est bien sûr du temps de développement additionnel pour le prestataire de développement mais rien d'absolument terrible.
Bien sûr, il peut y avoir des erreur. Mais encore une fois, du moment qu'il y a vérification manuelle ensuite, cela n'est pas un problème. On en revient toujours au même point: il faut comprendre la technologie et ses limites.
Il faut aussi filtrer selon la taille de la piscine ;
Une fois que tu as les objets détectés, la taille de la piscine n'est qu'une donnée comme une autre déjà présente quasi automatiquement (je pars du principe qu'on a toutes les données géographiques, donc de position et taille aussi, avec les images satellite).
Ensuite ajouter des champs dans un programme pour filtrer selon la taille de ces objets, c'est l'affaire d'une demi-heure de dév supplémentaire et de quelques heures de tests. Allez disons un jour ou 2 supplémentaires.
Je suis à peu près persuadé que la facture est énorme pour le service rendu (il y a une astuce : c’est toujours le cas sur ce genre de contrat).
Alors soyons clair, il est évident que comparer le "fait en 2 jours par un geek dans son coin" est plus une boutade pour faire la comparaison avec l'odieuse facture de 24 millions (en fait, c'est plus un "devis" là, car l'article parle de "coût estimé" et comme toujours, on voit venir les retards de projets, allongements d'une année ou deux, etc.). Bien sûr que le vrai service demandé va prendre plus de temps et donc d'argent.
Tout développeur sait que la première démo est faite vite fait à l'arrache dans un coin en quelques jours (voire heures), pour prouver le concept. Ensuite quand on veut aller plus loin et faire ça bien, y en a pour des jours, voire des semaines à peaufiner (si ce n'est refaire) le code, corriger les problèmes, découvrir de nouveaux problèmes.
Puis ensuite, une fois qu'on a l'algo bien rôdé, on le teste sur des jeux de données. Cette période de test peut durer des jours, voire des semaines si on veut faire ça bien avec beaucoup de données (beaucoup de gens ne comprennent pas que des fois, pour des patchs de quelques lignes de code, ce qui prend le plus de temps, c'est la période de test dans toutes les configurations possibles). Et puis y aura sûrement une interface (graphique et/ou non) pour l'accès, traitement, etc. des données.
Si on engageait ce même développeur, je dirais qu'on devrait sûrement lui donner un an pour finir le travail avec une équipe de 2/3 collègues. Allez disons 2 ans pour faire les choses vraiment vraiment bien (et parce qu'on a identifié tous les problèmes plus haut qui peuvent créer des situations vraiment injustes pour les contribuables identifiés par erreur, etc. Donc on veut mettre tout parfaitement au carré). Et même avec de superbes salaires (qu'ils méritent, comme toute personne qui travaille bien — et ça inclue votre boulanger, votre plombier, etc. ← ça c'est une remarque pour ceux qui continuent d'affirmer que c'est normal que les développeurs soient superbement mieux payés que d'autres "parce que vous comprenez, c'est compliqué" 🙄), et même en rajoutant 30% pour les imprévus et retards éventuels, et même en rajoutant un petit plus pour l'évolution de l'entreprise... ben on tombe pas sur ce type de somme exubérante.
Je ne comprends pas pourquoi il y a toujours des gens pour défendre ce type d’aberration, où notre argent de contribuable est dépensé absolument irraisonnablement, et ce toujours pour enrichir les mêmes. On sait tous comment ça marche: les cahiers des charges, les problèmes inattendus, les demandes particulières, etc. On connaît. Je connais pas du tout ce "geek" dont on parle ici, mais je suis persuadé que lui aussi connaît ces choses là et que si on lui demandait de chiffrer ce projet, il ne ferait pas une facture pour 2 jours de boulot seul. L'argument n'est pas là. L'argument est que quel que soit le chiffrage final, ce ne sera pas 24 millions d'euros.
Une telle somme d'argent publique donnée à une entreprise publique, toujours parmi les mêmes (c'est à dire parmi les quelques entreprises qui tournent autour des services publiques, qui se comptent sur les doigts des mains), et en plus qui a déjà démontré ne pas savoir répondre aux besoins simples, c'est une preuve d'incompétence de ceux qui décident (voire de corruption, selon certains, comme on le lit régulièrement, mais sans enquête... on ne peut pas dire).
Pour la démonstration d'incompétence (côté prestataire), je rappellerai ce logiciel pour la police de rédaction de plaintes qui avait été confié à CapGemini, a coûté 12 millions d'euros de notre argent public, a accumulé les retards, et après 5 ans de "travail", après un audit, on se rend compte que c'est inutilisable, au point même que c'est irrattrapable (mais ils ont fait quoi pendant 5 ans?) et le projet est simplement abandonné. Et évidemment comme le prestataire a "bétonné juridiquement son contrat" (cf. l'article en lien; le juridique, ça ils savent; faire des logiciels par contre...), rien ne sera fait contre eux (pas de retournement possible des services publics pour dédommagements, semblerait-il). On se contente d'accepter la perte sèche, financière et temporelle, et on repart pour un tour avec un nouvel appel d'offre.
Je sais pas vous, mais moi, lorsque j'engage un artisan pour un travail, qu'il me saccage tout et part sans finir le boulot, je le rappelle pas pour un nouveau projet. Pour les services publics apparemment, ça va!
Alors là aussi, je me rappelle bien que quand cette news était sortie, on lisait sur divers forums "non mais ça a l'air simple comme ça, mais y a sûrement un cahier des charges complexe" et patati et patata. Mais faut arrêter un peu. Le cahier des charges et la prise en charge du besoin, c'est la base de la base. Le B.A. BA. Tout développeur sait ça. On connaît et on sait faire. Ça fait partie de la description de l'emploi. Le problème n'est pas qu'il y ait un cahier des charges long comme le bras, complexe ou non, etc. Le problème c'est juste que si ce cahier des charges est réellement trop compliqué pour ces gens, faut peut-être songer à changer de métier et faut peut-être que nos organismes publics arrêtent de signer des contrats avec eux.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Deux jours, d’accord, mais sur quelle cible ?
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Combien pour un algorithme de détection de piscines sur les photos aériennes ?. Évalué à 10.
Si tu lis le forum OSM en lien plus haut, ce développeur estime à 5% de faux-positif. Dans tous les cas, un tel système est une aide. Le traitement réel doit passer par des humains de toutes façons, donc les faux-positifs, tant qu'ils ne sont pas de l'ordre de 50% (là, c'est que le système est cassé et n'a aucun intérêt), on s'en fout.
Le problème des faux-positifs, c'est quand un tel système de détection est utilisé seul pour prendre une décision. Et dans les décisions de type administratives/légales, les conséquences peuvent être graves. On a déjà vu ce genre de problème avec des gens arrêtés sur la seule base de reconnaissance facile défaillante, notamment pas mal aux US où ce genre de pratiques semble devenir courantes (voir ce cas, ou encore ce cas ou celui-là ou... en fait il semble y en avoir tellement depuis des années que c'en est ahurissant!).
Forcément personne n'aimerait avoir une amende pour une piscine non-déclarée alors... que cette personne n'a même pas de piscine (ils auraient peut-être étalé une bâche et ça a été pris pour tel ou autre faux-positif)! C'est pas pareil que se faire arrêter, mais avec les prises de tête administratives, notamment pour faire admettre les erreurs, le temps perdu, le stress... ce serait aussi très moche pour une famille de subir cela (d'autant plus pour des familles plus modestes pour lesquels ce genre de problèmes peut devenir dramatique).
Donc bon quel que soit le système, il faut une vrai vérification par un vrai humain, d'abord visuelle (pour détecter les faux-positifs évidents avec vérification sur écran) puis manuelle, sur place (pour les cas plus douteux: genre le coup de la bâche: il y a peut-être vraiment une piscine dessous!). Et ce, que le prestataire de développement soit CapGemini ou un geek dans son coin.
Ah et croire que CapGemini soit capable de faire cela sans aucun faux-positif aussi serait totalement absurde et ne ferait que montrer une incompréhension totale de la technologie. Comme toute technologie, il faut juste l'utiliser responsablement, ce qui inclue de la comprendre ainsi que ses limites.
Ça n'est pas pire que la situation actuelle dans le contexte de l'administration qui cherche à retrouver les gens qui ne déclarent pas les piscines. Autant les faux-positifs sont effectivement un réel danger (pour les citoyens honnêtes pris dans les filets de la technologie mal comprise par les administrations, donc pour une société juste dans son ensemble), autant les faux-négatifs ne changent pas grand chose. Les administrations doivent simplement continuer à faire un travail manuel pour trouver des piscines autrement, et ne pas compter exclusivement sur la sacro-sainte IA pour ces cas qui passent entre les mailles du filet.
Dans tous les cas, en soi, les faux négatifs sont beaucoup moins un problème, n'empirent pas la situation et ne créent aucun cas d'injustice comme pourraient le faire les faux positifs (qui effectivement doivent vraiment être regardés de près et pris en compte avec un grosse priorité dans le projet).
Ce qui peut ne pas être trivial est éventuellement le côté administratif, si les données cadastrales ne sont pas déjà proprement enregistrées, avec des API utilisables, et bien partagées entre administration. Que ce soit CapGemini ou un autre ne change pas la donne.
Mais si les infos sont déjà accessibles, techniquement il n'y a vraiment aucun problème à faire des rapprochements entre piscines détectées sur des images satellitaire et données cadastrales sur l'emplacement de piscines déclarées.
C'est bien sûr du temps de développement additionnel pour le prestataire de développement mais rien d'absolument terrible.
Bien sûr, il peut y avoir des erreur. Mais encore une fois, du moment qu'il y a vérification manuelle ensuite, cela n'est pas un problème. On en revient toujours au même point: il faut comprendre la technologie et ses limites.
Une fois que tu as les objets détectés, la taille de la piscine n'est qu'une donnée comme une autre déjà présente quasi automatiquement (je pars du principe qu'on a toutes les données géographiques, donc de position et taille aussi, avec les images satellite).
Ensuite ajouter des champs dans un programme pour filtrer selon la taille de ces objets, c'est l'affaire d'une demi-heure de dév supplémentaire et de quelques heures de tests. Allez disons un jour ou 2 supplémentaires.
Alors soyons clair, il est évident que comparer le "fait en 2 jours par un geek dans son coin" est plus une boutade pour faire la comparaison avec l'odieuse facture de 24 millions (en fait, c'est plus un "devis" là, car l'article parle de "coût estimé" et comme toujours, on voit venir les retards de projets, allongements d'une année ou deux, etc.). Bien sûr que le vrai service demandé va prendre plus de temps et donc d'argent.
Tout développeur sait que la première démo est faite vite fait à l'arrache dans un coin en quelques jours (voire heures), pour prouver le concept. Ensuite quand on veut aller plus loin et faire ça bien, y en a pour des jours, voire des semaines à peaufiner (si ce n'est refaire) le code, corriger les problèmes, découvrir de nouveaux problèmes.
Puis ensuite, une fois qu'on a l'algo bien rôdé, on le teste sur des jeux de données. Cette période de test peut durer des jours, voire des semaines si on veut faire ça bien avec beaucoup de données (beaucoup de gens ne comprennent pas que des fois, pour des patchs de quelques lignes de code, ce qui prend le plus de temps, c'est la période de test dans toutes les configurations possibles). Et puis y aura sûrement une interface (graphique et/ou non) pour l'accès, traitement, etc. des données.
Si on engageait ce même développeur, je dirais qu'on devrait sûrement lui donner un an pour finir le travail avec une équipe de 2/3 collègues. Allez disons 2 ans pour faire les choses vraiment vraiment bien (et parce qu'on a identifié tous les problèmes plus haut qui peuvent créer des situations vraiment injustes pour les contribuables identifiés par erreur, etc. Donc on veut mettre tout parfaitement au carré). Et même avec de superbes salaires (qu'ils méritent, comme toute personne qui travaille bien — et ça inclue votre boulanger, votre plombier, etc. ← ça c'est une remarque pour ceux qui continuent d'affirmer que c'est normal que les développeurs soient superbement mieux payés que d'autres "parce que vous comprenez, c'est compliqué" 🙄), et même en rajoutant 30% pour les imprévus et retards éventuels, et même en rajoutant un petit plus pour l'évolution de l'entreprise... ben on tombe pas sur ce type de somme exubérante.
Je ne comprends pas pourquoi il y a toujours des gens pour défendre ce type d’aberration, où notre argent de contribuable est dépensé absolument irraisonnablement, et ce toujours pour enrichir les mêmes. On sait tous comment ça marche: les cahiers des charges, les problèmes inattendus, les demandes particulières, etc. On connaît. Je connais pas du tout ce "geek" dont on parle ici, mais je suis persuadé que lui aussi connaît ces choses là et que si on lui demandait de chiffrer ce projet, il ne ferait pas une facture pour 2 jours de boulot seul. L'argument n'est pas là. L'argument est que quel que soit le chiffrage final, ce ne sera pas 24 millions d'euros.
Une telle somme d'argent publique donnée à une entreprise publique, toujours parmi les mêmes (c'est à dire parmi les quelques entreprises qui tournent autour des services publiques, qui se comptent sur les doigts des mains), et en plus qui a déjà démontré ne pas savoir répondre aux besoins simples, c'est une preuve d'incompétence de ceux qui décident (voire de corruption, selon certains, comme on le lit régulièrement, mais sans enquête... on ne peut pas dire).
Pour la démonstration d'incompétence (côté prestataire), je rappellerai ce logiciel pour la police de rédaction de plaintes qui avait été confié à CapGemini, a coûté 12 millions d'euros de notre argent public, a accumulé les retards, et après 5 ans de "travail", après un audit, on se rend compte que c'est inutilisable, au point même que c'est irrattrapable (mais ils ont fait quoi pendant 5 ans?) et le projet est simplement abandonné. Et évidemment comme le prestataire a "bétonné juridiquement son contrat" (cf. l'article en lien; le juridique, ça ils savent; faire des logiciels par contre...), rien ne sera fait contre eux (pas de retournement possible des services publics pour dédommagements, semblerait-il). On se contente d'accepter la perte sèche, financière et temporelle, et on repart pour un tour avec un nouvel appel d'offre.
Je sais pas vous, mais moi, lorsque j'engage un artisan pour un travail, qu'il me saccage tout et part sans finir le boulot, je le rappelle pas pour un nouveau projet. Pour les services publics apparemment, ça va!
Alors là aussi, je me rappelle bien que quand cette news était sortie, on lisait sur divers forums "non mais ça a l'air simple comme ça, mais y a sûrement un cahier des charges complexe" et patati et patata. Mais faut arrêter un peu. Le cahier des charges et la prise en charge du besoin, c'est la base de la base. Le B.A. BA. Tout développeur sait ça. On connaît et on sait faire. Ça fait partie de la description de l'emploi. Le problème n'est pas qu'il y ait un cahier des charges long comme le bras, complexe ou non, etc. Le problème c'est juste que si ce cahier des charges est réellement trop compliqué pour ces gens, faut peut-être songer à changer de métier et faut peut-être que nos organismes publics arrêtent de signer des contrats avec eux.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]