Connexion
Abonnez-vous

Le suivi des sans-abri gravement perturbé par un nouveau logiciel

Le suivi des sans-abri gravement perturbé par un nouveau logiciel

Le 05 octobre 2020 à 07h56

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. »

Le 05 octobre 2020 à 07h56

Commentaires (19)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

C’est beau….à force de vouloir compresser les prix, voilà le résultat.



Ils ne font pas de tests avant une MEP?

votre avatar

Les utilisateurs ne peuvent pas faire les tests si on ne fait pas de MEP avant. :byebye:

votre avatar
votre avatar

« Les tests, c’est pour ceux qui doutent »
(Phrase réellement entendue au détour d’un projet…)

votre avatar

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)

votre avatar

Ce sont les ritournelles courantes qu’on entend dans l’IT :




  • Tester c’est douter

  • Tester c’est prendre le risque de trouver une régression / un bug

  • La prod est la meilleure des recettes

  • La qualif c’est pour les enfants

  • La recette c’est pour ceux qui manquent de conviction dans la vie

  • Les procédures c’est pour ceux qui manquent d’imagination



etc.

votre avatar

dylem29 a dit:


C’est beau….à force de vouloir compresser les prix, voilà le résultat.



Ils ne font pas de tests avant une MEP?


Des tests? Ca se fait pas en prod, les tests? :keskidit:

votre avatar

Patch a dit:


Des tests? Ca se fait pas en prod, les tests? :keskidit:



bielorusse320 a dit:


Les utilisateurs ne peuvent pas faire les tests si on ne fait pas de MEP avant. :byebye:



tazvld a dit:


https://www.commitstrip.com/fr/2017/02/08/where-are-the-tests/


:mdr:

votre avatar

Chez moi, j’ai un peu l’impression que de vouloir travailler proprement, c’est interdit …




  • Cahier de scénarios de tests (tu appuies sur un bouton et tu regardes si la conséquence est conforme à l’attendu) : plusieurs mois que j’attends que mes utilisateurs aient terminé.

  • Cahier des charges ? Simple expression du besoin. Ah, et ça évolue tous les jours.

  • “Comment ça tu peux pas ? Mais l’autre logiciel a aussi cette faille, on peut bien en faire une ici, ça nous simplifierai la vie !”

  • “Dis, tu peux nous faire une bidouille, on a un fichier Excel qu’on souhaiterai mettre dans la Bdd et tu sais, nous on a pas le temps pour ça.”

  • “On veut mettre x données dans un tableau croisé dynamique, tu peux t’en occuper ?”



:dd:
Quand je penses que mes collègues acceptent toutes ces conneries sans broncher, c’est triste …

votre avatar

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.

votre avatar

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.

votre avatar


Arcy a dit:




:dd: Quand je penses que mes collègues acceptent toutes ces conneries sans broncher, c’est triste …


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.

votre avatar

numerid a dit:


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.
Probablement par désolation.


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 …

votre avatar

Arcy a dit:


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 …


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.

votre avatar

Pas de problème d’emploi ? Bien payé ?
:mdr: :non:

votre avatar

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 :-(

votre avatar

Encore une belle publicité pour la “French Tech” :fumer:

votre avatar

Après les admissions en université et les sans abris, à qui le tour ? :transpi:

votre avatar

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 :mdr:

Le suivi des sans-abri gravement perturbé par un nouveau logiciel

Fermer