IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualités
    Avatar de Michael Guilloux
    Homme Profil pro
    Data Consultant
    Inscrit en
    Juillet 2013
    Messages
    2 875
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Data Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2013
    Messages : 2 875
    Points : 86 930
    Points
    86 930
    Billets dans le blog
    2
    Par défaut USA : un site Web de 44 millions $ construit par Deloitte abandonné par la plupart des États à cause des bugs
    USA : un site Web de 44 millions $ construit par Deloitte abandonné par la plupart des États à cause des bogues informatiques
    le site était destiné à gérer la distribution des vaccins contre la Covid-19

    Au début de la pandémie de la Covid-19, les Centers for Disease Control and Prevention (CDC) des États-Unis ont souligné la nécessité d'être dotés d'un système capable de gérer une campagne de vaccination de masse, une fois les vaccins approuvés. Il voulait rationaliser le tout : inscriptions, planification, suivi des stocks et rapports de vaccination. « Il était clair que nous avions besoin d'un moyen de gérer ces centres médicaux, programmer le passage des personnes et essayer de nous assurer qu'elles reviennent pour leur deuxième dose », affirme Noam Arzt, président de HLN Consulting, qui aide à construire des systèmes d'information sanitaire.

    Ainsi, en mai 2020, les États-Unis ont confié cette tâche à la société de conseil Deloitte, avec un contrat sans appel d'offres de 16 millions de dollars pour gérer « la distribution et le suivi de l'administration des vaccins contre la Covid-19 ». En fait, Deloitte était le seul cabinet capable de répondre aux exigences du projet, car la configuration du système se fait à l’aide de la plateforme propriétaire GovConnect de Deloitte. Par conséquent, aucune autre entreprise ne peut accéder au système pour mener des activités d'exploitation et de maintenance.

    En décembre dernier, Deloitte a obtenu une rallonge budgétaire de 28 millions de dollars pour le projet. Si le contrat précisait que le budget pourrait aller jusqu'à 32 millions de dollars, c'est en fin de compte une facture d'un montant de 44 à 48 millions de dollars qui sera laissée aux contribuables.

    Le tout nouveau système, un site Web appelé VAMS (Vaccine Administration Management System), était censé être un guichet unique où les employeurs, les fonctionnaires, les établissements hospitaliers et les individus pourraient gérer la planification, l'inventaire et les rapports pour les vaccins contre la Covid-19, mais il semble avait complètement manqué le but. C'est d'ailleurs ce qu'a fait savoir Marshall Taylor, chef du département de la santé de la Caroline du Sud, aux législateurs de l'État. Il s'insurge contre le fait que le système a gravement nui à leurs efforts de vaccination jusqu'à présent. Confrontés à une série de problèmes et de bogues, plusieurs États, dont la Caroline du Sud, ont choisi de construire leurs propres solutions ou d'acheter pour des systèmes privés.

    Les agents de santé du Connecticut, de la Virginie et d'autres États affirment que le système annule de manière hasardeuse les rendez-vous. Il souffrirait de bien d'autres problèmes, y compris le fait que le personnel n'arrive pas à se connecter à l'interface qu'ils sont censés utiliser pour saisir les enregistrements. Le CDC reconnaît qu’il existe plusieurs défauts qu’il s’efforce de corriger, bien qu’il attribue certains des problèmes à une erreur de l’utilisateur.


    Ce n'est pas la première fois que l'argent du contribuable est utilisé sur des projets coûteux qui ne portent pas les fruits attendus. En 2017 par exemple, le gouverneur de la Pennsylvanie et son administration avaient porté plainte contre IBM évoquant les échecs du géant de la technologie dans la mise en place d’un système informatique de gestion des indemnités de chômage au sein de l’État.

    Le projet de système de modernisation de l’indemnisation de chômage (UCMS) a été attribué à IBM dans un contrat à prix fixe de 110 millions de dollars et avec une date de livraison prévue pour février 2010. L’expiration du contrat lui-même a été fixée pour l’année 2013. Mais en fin de compte, c’est un projet qui n’aurait jamais été livré alors qu’il a engendré des coûts de développement supplémentaires, comme celui de Deloitte. Le Département du Travail et de l’Industrie (DLI) de la Pennsylvanie, à qui le système était destiné, a également continué à supporter les coûts élevés liés à l’utilisation de son système existant, vieux de plus de 50 ans et qui utilise un logiciel qui n’était plus enseigné.

    Une chose est certaine, c'est que les échecs de projets informatiques sont des faits courants. D'ailleurs, plusieurs études ont été menées sur cette question, et la plupart s'accordent sur le fait qu'une bonne partie (parfois la majorité) des projets informatiques se soldent par un échec. Précisons que la notion d'échec ici signifie que soit le projet n'est jamais lancé ; soit il est lancé, mais n'est jamais terminé ; soit il est terminé, mais ne répond pas aux besoins exprimés par les utilisateurs. La question que l'on peut alors se poser est : quels sont les facteurs d'échec ou de réussite d'un projet informatique ?

    Source : MIT Technology Review

    Et vous ?

    Qu'en pensez-vous ?
    Quels sont selon vous les facteurs d'échec ou de réussite les plus importants d'un projet IT ? Partagez votre expérience.
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Expert éminent Avatar de marsupial
    Homme Profil pro
    Retraité
    Inscrit en
    Mars 2014
    Messages
    1 760
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Autre

    Informations professionnelles :
    Activité : Retraité

    Informations forums :
    Inscription : Mars 2014
    Messages : 1 760
    Points : 7 185
    Points
    7 185
    Par défaut
    Quels sont selon vous les facteurs d'échec ou de réussite les plus importants d'un projet IT ?
    Le temps donc l'argent et bien poser le cahier des charges.
    Repeat after me
    Le monsieur lutte pour la défense des libertés individuelles et collectives

    Repeat after me...

  3. #3
    Membre extrêmement actif
    Avatar de Ryu2000
    Homme Profil pro
    Étudiant
    Inscrit en
    Décembre 2008
    Messages
    9 553
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Décembre 2008
    Messages : 9 553
    Points : 18 448
    Points
    18 448
    Par défaut
    Citation Envoyé par Michael Guilloux Voir le message
    Le tout nouveau système, un site Web appelé VAMS (Vaccine Administration Management System), était censé être un guichet unique où les employeurs, les fonctionnaires, les établissements hospitaliers et les individus pourraient gérer la planification, l'inventaire et les rapports pour les vaccins contre la Covid-19, mais il semble avait complètement manqué le but.
    Dit comme ça on ne dirait pas que c'est un système extrêmement compliqué à mettre au point.

    Citation Envoyé par Michael Guilloux Voir le message
    En fait, Deloitte était le seul cabinet capable de répondre aux exigences du projet, car la configuration du système se fait à l’aide de la plateforme propriétaire GovConnect de Deloitte. Par conséquent, aucune autre entreprise ne peut accéder au système pour mener des activités d'exploitation et de maintenance.
    Comme Deloitte était certains d'avoir la tâche il n'a pas fait beaucoup d'efforts sur les prix, à la base il devait le faire pour 16 millions et au final ça a peut-être couté entre 44 et 48 millions.
    Peut-être que le site est toujours en cours de développement et qu'il finira par fonctionner correctement.

    Citation Envoyé par Michael Guilloux Voir le message
    Ce n'est pas la première fois que l'argent du contribuable est utilisé sur des projets coûteux qui ne portent pas les fruits attendus. En 2017 par exemple, le gouverneur de la Pennsylvanie et son administration avaient porté plainte contre IBM évoquant les échecs du géant de la technologie dans la mise en place d’un système informatique de gestion des indemnités de chômage au sein de l’État.
    Ça me rappelle vaguement des logiciels français :
    Le logiciel de soldes des militaires va être abandonné, histoire d'une gabégie
    L'Éducation nationale décide de débrancher SIRHEN, son logiciel visant à gérer son personnel qui a déjà englouti 320 millions d'euros
    ONP, Louvois, Sirhen : pourquoi Matignon peine à contrôler les projets informatiques de l’État

    Dans un autre domaine il y a ça :
    Parcoursup : gros cafouillage, des étudiants reçoivent des réponses favorables par erreur

    Citation Envoyé par marsupial Voir le message
    le cahier des charges.
    Dans le cas du site Web construit par Deloitte, est-ce que tu penses qu'il y avait un problème d'argent ou de cahier des charges ?

    Citation Envoyé par Michael Guilloux Voir le message
    Quels sont selon vous les facteurs d'échec ou de réussite les plus importants d'un projet IT ? Partagez votre expérience.
    Il faut développer un logiciel utile, qui va être utilisé, qui répond à des vrais besoins. (parfois des grosses sommes d'argent sont investit dans des logiciels qui ne seront jamais utilisé, il y a des développeurs qui ont travaillé des années pour rien)
    Les retours des utilisateurs finaux aident à orienter le projet dans la bonne direction.
    Keith Flint 1969 - 2019

  4. #4
    Membre éprouvé Avatar de scandinave
    Homme Profil pro
    Développeur Java, NodeJs/Angular
    Inscrit en
    Mai 2009
    Messages
    277
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Développeur Java, NodeJs/Angular

    Informations forums :
    Inscription : Mai 2009
    Messages : 277
    Points : 919
    Points
    919
    Par défaut
    Quels sont selon vous les facteurs d'échec ou de réussite les plus importants d'un projet IT ? Partagez votre expérience.
    Pour l'immense majorité des projets en échec que j'ai vu, il s'agit de projets demandés par une entité ayant un besoin mais pas de moyens, passant par une entité supérieur ayant elle, des moyens mais ni de besoin ni de connaissance métier. Cette entité supérieur délègue à un prestataire de service qui ne traite qu'avec l'entité supérieur.

    L'entité à l'origine de la demande est complètement exclue du processus jusqu’à livraison. Le résultat ?

    * Cahier des charges au fraises
    * Surcout
    * Projet ne répondant pas au besoin
    * Projet ne voyant jamais le jour.

    La solution pour remédier à cela ? Vous êtes une petite boite, continuer à une utiliser une société de service. Vous n'avez pas les moyens de développer un SI en propre. Par contre les boites de plusieurs dizaine de milliers de salariés, je ne comprends pas l'intérêt de passer par un prestataire externe. Ça coûte plus de pognon ( faut bien payer l’intermédiaire ) et des boite comme cela on toutes un/des SI complexe rendant viable d'avoir des équipes de développeur à plein temps.

  5. #5
    Membre expérimenté
    Homme Profil pro
    chomeur
    Inscrit en
    Avril 2015
    Messages
    709
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 79
    Localisation : France, Seine Maritime (Haute Normandie)

    Informations professionnelles :
    Activité : chomeur
    Secteur : Distribution

    Informations forums :
    Inscription : Avril 2015
    Messages : 709
    Points : 1 582
    Points
    1 582
    Par défaut
    encore un site Angular
    Plus vite encore plus vite toujours plus vite.

  6. #6
    Membre extrêmement actif
    Avatar de Ryu2000
    Homme Profil pro
    Étudiant
    Inscrit en
    Décembre 2008
    Messages
    9 553
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Décembre 2008
    Messages : 9 553
    Points : 18 448
    Points
    18 448
    Par défaut
    Citation Envoyé par scandinave Voir le message
    Par contre les boites de plusieurs dizaine de milliers de salariés, je ne comprends pas l'intérêt de passer par un prestataire externe. Ça coûte plus de pognon ( faut bien payer l’intermédiaire ) et des boite comme cela on toutes un/des SI complexe rendant viable d'avoir des équipes de développeur à plein temps.
    Ouais je ne comprend pas non plus pourquoi des grosses entreprises utilisent autant de prestataires.
    Le seul avantage que je vois c'est qu'il est facile de mettre fin à un contrat, alors que quand t'embauches quelqu'un en CDI c'est beaucoup plus compliqué. (d'ailleurs ça me fait penser qu'en ce moment, les SSII doivent pousser ceux qui sont en inter-contrat à faire des ruptures conventionnelles)
    Keith Flint 1969 - 2019

  7. #7
    Membre averti
    Profil pro
    Développeur Full Stack
    Inscrit en
    Janvier 2012
    Messages
    69
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Full Stack

    Informations forums :
    Inscription : Janvier 2012
    Messages : 69
    Points : 300
    Points
    300
    Par défaut
    Comme le dit @scandinave, la source de ces problèmes est souvent une déconnexion entre le besoin et les équipes qui développent. Il y a plusieurs facteurs qui entrent en jeu ici :
    - Le client final est peu impliqué et/ou peu formé à la maitrise d'ouvrage
    - L'analyse du besoin est déléguée à des consultants qui ne sont pas du métier
    - La taille du projet et de la structure fait que les informations passent par de nombreuses personnes pas forcément concernées
    - Les hiérarchies côté client comme côté prestataire sont grevées par des questions d'égo, plus que de volonté de faire aboutir le projet
    - Les développeurs sont à des années lumières des utilisateurs

    A cela se rajoute des circonstances aggravantes :
    - Client captif d'un système propriétaire
    - Ce même système propriétaire est spécifique au client, donc ne bénéficie d'aucune amélioration mutualisée, ce qui abouti en général à une complète absence de documentation, de maintenance, et même d'équipe ayant une bonne connaissance du système
    - Contexte politique

    Voilà tout un tas de facteurs qui expliquent ce genre de dérives.

    La plupart sont des facteurs inhérents aux grosses structures, mais les petites structures peuvent aussi souffrir de ce genre de problème. Le problème le plus courant, à mon sens, est lié au fait que les clients parfois ne se rendent pas compte de l'ampleur d'un projet et qu'un projet trop grand que l'on veut lancer en une seule phase, est souvent lié à l'échec, surtout lorsqu'on fait appel à un prestataire externe.

    Un projet trop grand, que l'on veut lancer en une seule phase, dont on néglige la modularité, est souvent un échec dès le départ car il est très difficile de se projeter sur l'ensemble des spécifications et le client se rend souvent compte en cours de route que certaines choses manquent. Idem pour les développeurs qui s'aperçoivent souvent en cours de route que la spec est défaillante et toutes ces petites erreurs de ci de là s'ajoutent et créent un problème qui fini par faire s'écrouler le château de cartes.

    Lorsqu'une société développe en interne pour elle-même, elle peut essayer rectifier le tir, mais lorsqu'il s'agit d'un prestataire, personne ne rectifie (par manque de temps, par manque d'implication), jusqu'au moment où on s'approche de la livraison et ces projets finissent par être les plus gros échecs.

    A mon sens le plus grand facteur non humain de réussite pour un projet est la phasage. Découper un projet en phases permet d'avoir des étapes où le client et le prestataire peuvent se retrouver et ajuster le tir au cas où le projet ne va pas dans la bonne direction. Pour le reste, les facteurs humains sont primordiaux : La vision du projet, la communication entre équipes, l'implication, et seulement à la fin, la compétence de chacun.

  8. #8
    Membre chevronné

    Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    Février 2004
    Messages
    758
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information

    Informations forums :
    Inscription : Février 2004
    Messages : 758
    Points : 2 086
    Points
    2 086
    Par défaut
    En même temps, on parle de Deloitte. Pour avoir travaillé avec eux, le résultat n'est pas du tout étonnant : très cher pour des résultats au mieux inconsistants.

  9. #9
    Membre extrêmement actif
    Homme Profil pro
    Technicien de maintenance / Developpeur PHP
    Inscrit en
    Mai 2015
    Messages
    428
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Technicien de maintenance / Developpeur PHP
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Mai 2015
    Messages : 428
    Points : 1 625
    Points
    1 625
    Par défaut
    Qu'en pensez-vous ?

    J'en pense que mon premier reflexe a été de me dire, "Mais c'est quoi Deloitte ?" tout ça pour m'apercevoir qu'il s'agit d'une société d' "Audit & Conseilles", donc pas étonnant que leurs projets IT ne tiennent pas trop la route .
    Et puis bon, le gouvernement qui accepte de reposer sur du logiciel proprio, n'a que ce qu'il mérite, juste désolé pour les administrés qui n'ont rien demandés eux.

    Quels sont selon vous les facteurs d'échec ou de réussite les plus importants d'un projet IT ? Partagez votre expérience.

    En l'Etat des connaissances dans le domaine de la gestion de projets, je dirais bien le sens du vent les soirées de pleine Lune .
    Non, sérieusement, personne n'est capable de donné les raisons de la réussite ou de l'échec d'un projet a priori, avant sa mise en œuvre effective.
    Si quelqu'un vous dit le contraire, soit il vous ment, soit il vous prend pour un c** (ou les deux, c'est possible ).
    A posteriori, l'échec ou la réussite peuvent être étudié, mais ça revient à faire des stats sur des sportifs, ça vous donne une "idée", mais ça n'est pas déterminant pour le future.

    Personnellement, j'ai vu des Chef de Projet / Dirigeant venir se vanter d'être des "très bons" (pour ce que ça veut dire) devant des clients, des équipes IT & autres, tout ça pour au final ce rendre compte que leurs taux de réussite reposait en fait sur une ou deux personnes dans l'équipe qui faisaient du bon taf.
    Malheureusement, on ne s'en rend compte qu'une fois les dites personnes partie.
    J'appelle ça le facteur "réel", c'est l'écart entre le rêve et la réalité dans la gestion de projets .

  10. #10
    Membre expérimenté
    Homme Profil pro
    retraité
    Inscrit en
    Septembre 2014
    Messages
    604
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : retraité

    Informations forums :
    Inscription : Septembre 2014
    Messages : 604
    Points : 1 441
    Points
    1 441
    Par défaut
    Citation Envoyé par scandinave Voir le message
    Pour l'immense majorité des projets en échec que j'ai vu, il s'agit de projets demandés par une entité ayant un besoin mais pas de moyens, passant par une entité supérieur ayant elle, des moyens mais ni de besoin ni de connaissance métier. Cette entité supérieur délègue à un prestataire de service qui ne traite qu'avec l'entité supérieur.

    L'entité à l'origine de la demande est complètement exclue du processus jusqu’à livraison. Le résultat ?

    * Cahier des charges au fraises
    * Surcout
    * Projet ne répondant pas au besoin
    * Projet ne voyant jamais le jour.

    La solution pour remédier à cela ? Vous êtes une petite boite, continuer à une utiliser une société de service. Vous n'avez pas les moyens de développer un SI en propre. Par contre les boites de plusieurs dizaine de milliers de salariés, je ne comprends pas l'intérêt de passer par un prestataire externe. Ça coûte plus de pognon ( faut bien payer l’intermédiaire ) et des boite comme cela on toutes un/des SI complexe rendant viable d'avoir des équipes de développeur à plein temps.
    Le but est de diminuer la masse salariale, et tout ce qui en découle, et faire pression sur les salaires des internes, alors assez faciles à remplacer.

  11. #11
    Membre expérimenté
    Homme Profil pro
    retraité
    Inscrit en
    Septembre 2014
    Messages
    604
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : retraité

    Informations forums :
    Inscription : Septembre 2014
    Messages : 604
    Points : 1 441
    Points
    1 441
    Par défaut
    Citation Envoyé par Ryu2000 Voir le message
    Ouais je ne comprend pas non plus pourquoi des grosses entreprises utilisent autant de prestataires.
    Le seul avantage que je vois c'est qu'il est facile de mettre fin à un contrat, alors que quand t'embauches quelqu'un en CDI c'est beaucoup plus compliqué. (d'ailleurs ça me fait penser qu'en ce moment, les SSII doivent pousser ceux qui sont en inter-contrat à faire des ruptures conventionnelles)
    Exact, en période de confinement l'an dernier, il y en a eu de ces propositions.

  12. #12
    Membre extrêmement actif
    Avatar de Ryu2000
    Homme Profil pro
    Étudiant
    Inscrit en
    Décembre 2008
    Messages
    9 553
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Décembre 2008
    Messages : 9 553
    Points : 18 448
    Points
    18 448
    Par défaut
    Citation Envoyé par TotoParis Voir le message
    Le but est de diminuer la masse salariale, et tout ce qui en découle, et faire pression sur les salaires des internes, alors assez faciles à remplacer.
    Mais ça coute ultra cher de prendre un prestataire.
    Parfois le client doit payer 500€/j et l'ingénieur de la SSI doit toucher 100€ net. (il me semble qu'il existe des ordres de grandeurs de ce type)

    Peut-être que les comptables comprennent comment ça fonctionne, il y a peut-être une histoire de diminution d'impôt ou quelque chose.

    Citation Envoyé par TotoParis Voir le message
    Exact, en période de confinement l'an dernier, il y en a eu de ces propositions.
    C'est ça ou la faillite, les SSII embauchent en CDI, quand les prestataires n'ont plus de mission, la SSII perd rapidement de l'argent (bon là ça va l'état aide beaucoup à payer les chômages).
    Si le gouvernement arrêterait les aides, ça partirait peut-être en plan sociaux. (et ce serait fini de pousser les types à faire des rupture conventionnelles)
    Keith Flint 1969 - 2019

  13. #13
    Expert éminent
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    Juillet 2004
    Messages
    4 205
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : Juillet 2004
    Messages : 4 205
    Points : 9 127
    Points
    9 127
    Par défaut
    Echec ou réussite pour moi là n'est pas le problème.

    Ce qui me fait bondir c'est "En fait, Deloitte était le seul cabinet capable de répondre aux exigences du projet, car la configuration du système se fait à l’aide de la plateforme propriétaire GovConnect de Deloitte. Par conséquent, aucune autre entreprise ne peut accéder au système pour mener des activités d'exploitation et de maintenance."

    Nous avons en France et en Europe des lois sur les marchés public. Elles sont contraignantes et ont pour but de garantir la "libre concurrence". en clair il s'agit de luter contre les passe droits et les pots de vin.

    Mais voilà on a à faire à de vrais requins, et je ne compte pas dans ma carrière le nombre de fois où j'ai vu un prestataire de marché (celui qui à gagné) faire en sorte de devenir incontournable. La solution est souvent la même. On répond au marché et on place stratégiquement dans la solution des élément propriétaires dont on a l'exclusivité.
    On lit l'appel d'offre et on constate souvent qu'à la périphérie il va y avoir un petit vide à combler. On se garde bien de le signaler. et lorsqu'on a le marché on lève le lièvre. L'administration est bien embêté et se demande comment elle va bien pourvoir faire. Alors on arrive en douceur. et on fini par glisser qu'on va faire un effort. "Vu le marché qu'on vient de passer on va vous le proposer gratuitement (pour 2 ans)"
    ET hop tu te retrouve avec un truc propriétaire que tu va devoir maintenir et dont ton prestataire à l'exclusivité. si au passage dans le coeur du marché il peut faire pareil, il ne s'en prive pas.

    Résultat tu est pieds et poings liés. Tu te dis que pour le marché suivent du va ajouter des clauses pour empêcher ça. Et là Paf tu te prends un procès pour entrave à la concurrence. Non seulement tu te tape les frais de procédure, mais tu pers un an pour refaire ton marché. Et pour bien te faire comprendre que t'es pris à la gorge, le postulant au marché ne dépose pas sa plainte lorsque le marché et publié. Non il attend le dernier jours avant le dépôt de candidatures. Histoire que tu perde un max de temps donc d'argent.

    Vous allez dire que j'exagère mais que penser lorsqu'un grand nom de l'informatique répond à un marché de développement logiciel avec 4 développeurs, 1 architecte chef de projet, et 9 juristes! Moi je comprends que ce candidat là ne répond pas pour nous fournir un logiciel, mais pour ancrer son pouvoir.

    Vous allez dire que je peux l'écarter. C'est bien mal connaitre les marchés public. Lorsqu'on veut passer un marcher on doit exprimer un besoin, au pire un cahier des charge. Si on dépasse ce stade c'est à dire passer un marché sur des spécifications formelles ça commence à coincer. certain acteurs ne vont pas se gêner pour dénoncer le fait qu'on a fait des choix qui entrave la concurrence. Donc on en reste au besoin. le Quoi et le Comment c'et au titulaire du marché de le fournir. Déjà là on voit qu'il y a quelque chose de pas normal. Avec ce besoin, on publie les points sur lesquels seront évalués les candidats. si dans une réponse il y a des choses qui ne sont pas prévues dans l'évaluations il est interdit d'en tenir compte. Donc préparer un marché ne se fait pas à la légère. En suite pour chaque point à évaluer il faut publier la notation. Associé à tout ça on fournis un Cahier de Cohérence Technique. Mais là encore on est limité dans les choix. Il est interdit d'imposer une technologie. Il est interdit d'écarté une technologie. la seule chose qu'on peut faire c'est de prévoir dans la notation un point sur chaque point technologique de la réponse et de mal noter un candidat qui est hors du cahier de cohérence. Cela n'entre que dans la note technique de l'évaluation du candidat. Et ce ne doit pas être une part disproportionnée de cette note technique. Il faut aussi ajouter que les personnes qui évaluent techniquement la proposition du candidat ne sont pas celle qui évaluent la partie financière. Et si une solution technique est hors du cahier et que en tant que technicien on sait que cela va impliquer un sur coût il n'est pas possible de donner une note financière pour rétrograder le candidat. Et généralement les évaluateurs de la partie financière n'ont aucune idée de ce surcoût. Et pour finir dans beaucoup trop d'administration si on prépare un marché et qu'on défini un notation qui dont la note technique compte pour 50% on se fait bouler et on recommence. généralement c'est 65% pour la note financière.

    Les requins mettent leur armé de juristes sur le sujet et vont chercher tous les interstices par lesquels il font soit pouvoir grater du fric, soit installer une bombe. Un petit truc qui n'a pas d'importance immédiate mais qui à long terme leur permettra de régner en maitres. Par exemple placer un produit propriétaire dont le cout annuel est basé sur le nombre de CPU ou la volumétrie ou le nombre d'utilisateur. Mais il ne sera pas placer de cette façon, on va même éviter de diffuser cette information. Non on va le mettre dans le marché à un prix dérisoire avec une licence Site pour la durée du marché. Et il faut ce souvenir qu'un candidat ne peut pas être évalué sur ce qui n'est pas dans le marché. Du coup l'administration qui a passé le marché ayant une licence site, ne va pas se poser de questions quand durant le marché le prestataire va lui suggérer d'installer une plateforme de Dev de test d'intégration de recette de préprod de prod voir même un deuxième recette pour en avoir une en phase avec la prod et une autre en avance de phase. Et au bout des 3 ans du marché le prestataire sachant qu'il est seul à pouvoir répondre va laisser passer les dates de renouvellement. le nouveau marché et caduque et il en prends pour un an de plus. L'administration se retrouve sans support. Le but forcer l'administration à ne plus passer par un marché ouvert (à un seul candidat) mais à un marché négocié. Car là le prestataire est en position de force. Si ça ne fonctionne pas il répond au marché ouvert mais exige le paiement des droit d'entré dans le support puisque l'administration l'a quitté. de plus on demande le paiement des licences des plateformes installées vu que le marché été fini l'administration a "délibérément" utilisé des logiciels pour lesquels elle n'avait pas payer les licence. Et là on sort le mode de licence au CPU au volume à l'usager... etc. Et si par malheurs vous décidé de ne pas passer de marcher mais d'abandonner la solution. Le prestataire sur cette base va vous mettre au tribunal.

    Je crois que vous avez compris. Nous nous sommes doté de lois pour luter contre les "fonctionnaires véreux" et nous en avons fait une arme pour pomper le fric des administrations.
    Vous aurait peut être noté qu'à aucun moment il a été question de la qualité de la prestation. Et pour cause la loi interdit de tenir compte des résultats d'une prestation d'une société lorsqu'elle postule pour un autre marché ou un renouvellement.

    En resumé vous devez rester vague sous peine d'entrave à la concurrence, vous n'avez pas de moyen d'écarter un truant, et vous en pouvez lui tenir rigueur de ne pas avoir par le passé tenu ses engagements.

    A+JYT

  14. #14
    Candidat au Club
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Août 2018
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Gard (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Août 2018
    Messages : 1
    Points : 3
    Points
    3
    Par défaut
    Avec un peu d'expérience, il est très facile de déterminer la méthode utilisée par ce genre de projets

    Source : https://www.la-rache.com/


    La Rache s’appuie sur deux concepts aussi important l’un que l’autre.

    D’une part la «Rapid Application Conception » correspond conceptuellement à une accélération importante dans la phase de conception de l'application par rapport aux méthodes classiques. Pour bien débuter avec La RACHE il faut soigner la phase d'étude et la rédaction du cahier des charges. Il faut ici produire un travail de synthèse important en résumant le cahier de charges en un post-it de 8 mots maximum. Puis la mission est d’extrapoler de ce post-it un sujet de développement vaseux, mais pas trop. À partir de là, en règle générale, la multiplication du nombre de mots sur le post-it par un chiffre tiré au sort entre 20 et 200 donne la durée du projet en jours/homme. On prendra soin de ne rien planifier dans cette phase.

    D'autre part « L’extrême programming heuristique » est un concept assez prometteur. En effet l’heuristique est une technique consistant à apprendre petit à petit, en tenant compte de ce que l'on a fait précédemment pour tendre vers la solution d'un problème. Opposé à l’algorithmique, l'heuristique ne garantit pas du tout qu'on arrive à une solution quelconque en un temps fini. Ceci sous-entend d’une part une démarche pédagogique globale d’apprentissage et de capitalisation des acquis, mais aussi que les échéances annoncées le sont dans une pure optique de déconnade symbolique. Et c’est précisément le plus ‘produit’ de la méthode RACHE.

    Cycle typique d'utilisation de La RACHE

    Nom : cycle.jpg
Affichages : 1191
Taille : 19,4 Ko

    Exemple de process conforme à La RACHE :

    Nom : process.jpg
Affichages : 1205
Taille : 60,2 Ko

  15. #15
    Futur Membre du Club
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Octobre 2014
    Messages
    2
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Octobre 2014
    Messages : 2
    Points : 6
    Points
    6
    Par défaut
    Je suis d'accord avec les raisons données par @clorr ou @scandinave.

    Mais ça me fait penser que depuis quelques années maintenant, on essaye d'éviter cet "effet tunel" jusqu'à la livraison, tellement source de tension et d'échec. Notamment par l'agilité. Scrum et autres.
    Quelqu'un parlait de phasage, oui, et je dirais même Itérations : dev, livraison partielle, on boucle, etc...
    Ce n'est pas encore parfait, ça ne résoud pas tout, mais au moins on limite la casse et l'effet "finalement ça marche pas" au bout de X mois de boulot. Non ?

    Et si ça doit échouer, autant échouer tôt, ça coute moins cher. "Fail fast".

Discussions similaires

  1. Réponses: 8
    Dernier message: 04/08/2018, 00h42
  2. Réponses: 2
    Dernier message: 06/04/2017, 22h47
  3. Réponses: 5
    Dernier message: 09/04/2016, 10h39
  4. Réponses: 10
    Dernier message: 18/08/2015, 18h12
  5. Site web inaccessible en se connectant par un switch
    Par sedik.h dans le forum Hébergement
    Réponses: 0
    Dernier message: 02/03/2012, 17h24

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo