Alors qu’un sans-abri sur deux ne trouve déjà pas de place en France, une série de bugs informatiques vient aggraver la prise en charge des demandes, révèle Jacques Duplessy dans Mediapart.
Le logiciel (dit SI-SIAO) est utilisé chaque jour par 15 000 à 20 000 travailleurs sociaux en France pour saisir les données des demandeurs d’hébergement d’urgence des personnes à la rue ou leur relogement à plus long terme. Il est censé fusionner avec le logiciel de pilotage des écoutants du 115.
Sa nouvelle version est une « catastrophe », explique Christine Laconde, la directrice du Samu social de Paris : « il y a une myriade de petits et gros bugs. On a l’impression que c’est l’Everest par la face nord, de nuit et sans crampons ». « Depuis, c’est le chaos », confirme Florent Guéguen, le directeur de la Fédération des acteurs de solidarité (FNARS), qui fédère 800 associations et 80 % des centres d’hébergement en France.
« On ne voit plus dans la base de données les personnes déjà enregistrées, beaucoup de rapports des travailleurs sociaux ont été perdus dans toute la France. On ne sait plus les places disponibles dans les centres d’hébergement car les disponibilités ne s’affichent plus en fonction de la taille du ménage qui fait la demande. Le RGPD n’est absolument pas appliqué. Les règles déontologiques ne sont pas respectées. Et en plus, la chef de projet côté État a été débarquée juste après le confinement. »
Commentaires (19)
#1
C’est beau….à force de vouloir compresser les prix, voilà le résultat.
Ils ne font pas de tests avant une MEP?
#1.1
Les utilisateurs ne peuvent pas faire les tests si on ne fait pas de MEP avant.
#1.2
https://www.commitstrip.com/fr/2017/02/08/where-are-the-tests/
#1.3
« Les tests, c’est pour ceux qui doutent »
(Phrase réellement entendue au détour d’un projet…)
#1.4
“Tester, c’est douter”
“Corriger, c’est abdiquer” (malheureusement, la boutique étant fermé, je n’ai pas réussi à retrouver des images officielles des posters)
(commitstrip est une perle pour tous ce qui touche au dev)
#1.5
Ce sont les ritournelles courantes qu’on entend dans l’IT :
etc.
#2
Des tests? Ca se fait pas en prod, les tests?
#3
#4
Chez moi, j’ai un peu l’impression que de vouloir travailler proprement, c’est interdit …
Quand je penses que mes collègues acceptent toutes ces conneries sans broncher, c’est triste …
#4.1
Honnêtement si tu commences à faire tout le cycle en V tu passes 90% de ton temps à faire du non-productif. Il faut un peu de souplesse d’esprit : Un cahier des charges n’est jamais complet (c’est normal) Beaucoup de ces docs n’ont pas forcément d’autre utilité que chercher un coupable quand ça ne marchera pas.
Faire des fiches de tests ou des spec techniques et l’exemple typique de truc inutile : dans la majorité des cas ce n’est pas rejouable et la spec est du pseudo-code, le développeur passe un temps de fou à faire des captures d’écrans et remplir un cahier de preuve de test il fait sa spec technique en rétrodoc. Résultat il passe un temps de dingue sur ces dos parfaitement inutiles (une spec technique qui est du code traduit en français au temps aller voir le code directement). Au final s’il avait passé ce temps à tester son programme et relire / commenter son code la qualité et la maintenabilité auraient été meilleure.
Il faut garder à l’esprit que le cycle en V date de l’assembleur à l’époque analyste technique était un métier. Aujourd’hui l’analyse technique est faite à 90% par ton compilateur.
Je suis persuadé que l’échec de ce projet est lié à ce mode de “gestion” : Tout le monde est couvert par son petit doc (c’est pas dans le cahier des charges, c’est pas dans la spec fonctionnelle, la spec technique, le devis), et finalement le besoin n’est pas couvert parce que tout le monde a été trop occupé à faire de la paperasserie plutôt que d’aller sur le terrain voir les pb des utilisateurs pour comprendre et répondre à l’entièreté du problème.
#4.2
Rassure-toi, les scénarios de tests sont juste là pour que l’utilisateur teste à fond le programme, et c’est uniquement pour les grosses applications (10 heures à rédiger des scénarios contre plus de 350h de développement applicatif).
Pour le cahier des charges, je comprend le fait qu’il puisse jamais être exact. Mais je pense surtout aux nombreuses contradictions et l’utilisateur qui change d’idée comme de chemise.
Après oui je suis d’accord, un code parfaitement commenté et compartimenté fait 90% du travail, du développement à la maintenance.
#5
C’est bien ce qui me chipote dans l’affaire, c’est qu’il y a des gens qui ont développé ça sans broncher.
#6
Tu bronches, on te reproche que c’est pas ton boulot, il faut que le travail soit fait dans les temps, et tu bâcles.
Tristesse …
#7
certes, mais bon, on a affaire à des gens qui n’ont pas de problèmes pour retrouver un emploi. On s’attendrait à un peu plus d’éthique et de conscience professionnelle de leur part surtout qu’ils sont bien payés généralement.
#7.1
Pas de problème d’emploi ? Bien payé ?
#8
Il y a probablement aussi un peu de la magie de l’administration : on ne développe plus rien en interne mais on fait faire par une entreprise pour beaucoup plus cher. Mais on ne sait pas plus gérer les projets avec les entreprises que les compétences internes en développement d’avant…
Côté entreprise, on voit l’administration arriver, et on se frotte les mains parce qu’on sait qu’on va pouvoir la pigeonner. Après viennent les difficultés parce que l’administration ne sait pas s’organiser, donc ne sait pas exprimer le besoin etc…
C’est affligeant de voir ce qui est fait avec notre argent :-(
#9
Encore une belle publicité pour la “French Tech”
#10
Après les admissions en université et les sans abris, à qui le tour ?
#11
ca existe encore les cahiers des charges / spec fonctionnelles de centaines de pages dans l’IT ? Maintenant c’est une suite de tickets jira / trello, le fameux exemple agile : tu codes une roue, puis tu améliore pour faire une trottinette, puis un vélo, puis une moto, puis une voiture EZ
Pour peu qu’on te laisse pas refacto / optimiser, tu as une voiture avec des roues et un chassis de trottinette