Echec des projets informatiques : 4 causes majeures

Don défiscalisé 10€ ou plus

Obtenez une réduction fiscale de 66% avec un e-reçu. Un don de 10 € ne vous coûte que 3€40.

Grâce à votre aide, AgoraVox peut continuer à publier plus de 1000 articles par mois. En donnant à la Fondation AgoraVox, vous offrez un soutien à la liberté d'expression et d'information.

Les réactions les plus appréciées

Réactions à cet article

• Par Halman (---.---.---.98) 11 décembre 2009 15:10

  

  Excellent article.

  Les projets (on appelait ça programme il y a quelques dizaines d’années, mais en argot informatique les modes évoluent) sont détruits dans l’oeuf dès la première phase de la conception.

  Lorsque une direction se réveille et décide d’enfin remplacer un logiciel obsolète depuis 20 ans c’est déjà bien trop tard, les agents ayant déjà pris et s’étant incrusté leurs petites habitudes indécrotables jusqu’à la retraite.

  Lors de la constitution du cahier des charges en passant par la réunion avec les utilisateurs, on fait l’erreur d’accepter de concevoir une interface à l’ancienne pour ne pas désapointer les utilisateurs habituels. Ainsi sur un os graphique actuel on hésite pas à concevoir un logiciel à l’interface à l’ancienne, monoécran, monotache, à la ms.dos... faisant conserver à l’utilisateur un mode de fonctionnement antédiluvien. Plutôt que le forcer à se faire au multifenetrage, à glisser les données d’une fenetre à une autre au lieu de les copier sur un bout de papier pour le resaissir dans l’écran suivant...

  On voit ainsi dans l’administration ces derniers temps apparaitre un logiciel de prise de rendez vous pour les médecins dont les manipulations sont du niveau de la check list de 747 plutot que du simple glisser déposer d’une fenetre à l’autre pour un simple changement de date de rendez vous.

  Et il parait que l’informatique est faite pour faire avancer les choses...

  Et ce sont les directions qui se battent pour trouver le bon fournisseur.

  Et ce sont les programmeurs en désaccords avec les collègues et leurs cadres qui programment à leur manière sans tenir compte des besoins de l’utilisateur, des normes d’ergonomies, de l’homogénéïté, chacun à sa manière et à son look perso et habituel.

  Et ça dure des mois voir des années.

  Et on nous livre une version 1 du logiciel dont la moitié des fonctions sont non « implantées » (à une époque on disait non compilée) et les autres qui plantent à la deuxième utilisation : téléphoner à la hotline en urgence.

  Dont les didactitiels, elearnings et documents sont bourrés de fautes toutes les lignes, bourrés de plantages de timings dans les pps, tout à refaire !

  Et l’utilisateur de pester encore contre l’informatique et d’en donner une image déplorable.

  Quand je parle d’utilisateur, je pense aussi bien la nana qui utilise son vocabulaire très particulier du genre « passer de l’autre coté de l’ordinateur » pour vouloir dire « ouvrir sa session bureautique » à celle qui croit maitriser Excel depuis 20 ans et qui ne connait pas l’existence des tableaux croisés dynamiques.

  Je suis formateur sur des logiciels des hopitaux depuis 10 ans, j’ai vu des logiciels de la conception à la formation des utilisateurs sur les versions « définitives » qu’on nous patche par surprise tous les 6 mois en nous prévenant la veille voir pas du tout.

  A tous les niveaux c’est du grand n’importe quoi.

  On tient compte des exigences des patrons de services pour la conception, qui bien sur ont un avis des plus différents sur l’engin, alors ça donne un logiciel qui n’est qu’un ramassis de fonctionnalités aux ergonomies conçues par des programmeurs différents, le tout sans grande concertation et homogénéïté, déconcertant et décourageant les utilisateurs qui passent plus de temps en manipulations gonflantes qu’en actions simples, rapides, pratiques, efficaces.

  Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
  • Par Alois Frankenberger (---.---.---.132) 11 décembre 2009 21:18

    

    @ Halman
    
    Ce que vous dites est curieux : ils ne font pas des programmes multi-tier chez vous ?
    
    Histoire de pouvoir changer d’interface graphique à volonté ...

    Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
• Par finael (---.---.---.53) 11 décembre 2009 15:12

  

  Vous oubliez une cause majeure.
  
  J’en parle avec 30 ans d’expérience derrière.
  
  La réalisation desdits projets est souvent confiée à des sociétés extérieures : les SSII.
  
  Dans ces sociétés, « pour emporter le marché », coûts et délais sont minorés au delà de l’imaginable.
  
  En 97 j’ai réalisé un projet plutôt complexe, dans les délais ... et j’ai reçu un blâme de ma boite (une SSII donc).
  
  « C’est sur les prolongations de contrat que je fais du gras ! »
  
  Authentique.
  
  D’autre part, pour appliquer correctement le Mode Projet, il faudrait des gestionnaires un minimum compétents ... ce qui n’est jamais le cas.

  Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
  • Par curieux (---.---.---.80) 11 décembre 2009 18:22

    

    Il ne faut pas non plus mésestimer les magouilles où la direction informatique a déjà choisi qui allait emporter le contrat, (sans oublier les rétro-commissions). La grande société bleue nous a envoyé quelques soi-disant ingénieurs avec un tas d’informaticiens qui sortaient de l’IUT et qui six mois plus tard étaient balançés chez d’autres clients, mais en tant que spécialistes.
    De toute façon, sans parler de collusion, la difficulté n’est pas admise, les délais sont largement sous-estimés, les cahiers des charges insignifiants, la technique ignorée afin de laisser la place à des usines à gaz comme on dit.
    Les sociétés ont commencé a investir honteusement sans des logiciels de méthodes fumeuses, lourdes qui font que le temps à faire de la paperasse mange le temps de la réalisation concrète.

    Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
  • Par finael (---.---.---.53) 11 décembre 2009 19:02

    

    @ curieux
    
    Tiens ! La grande bleue !
    
    J’y ai bossé (en tant qu’intervenant bien sûr) en 96.
    
    Source interminable d’anecdotes dont on ne sait pas très bien s’il faut en rire ou en pleurer.

    Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
  • Par curieux (---.---.---.80) 11 décembre 2009 19:12

    

    Oui, la grande Bleue, très forte en papiers d’administration, beaucoup plus qu’en technique

    Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
  • Par L’enfoiré (---.---.---.142) 12 décembre 2009 09:10

    

    Salut Finael,
     Je reconnais tout de suite ceux qui en ont fait partie du « grand jeu ».
     Ce n’est pas uniquement, en informatique que l’on fait appel à l’outsourcing, à des deuxièmes couteaux, mais en informatique, réduire les coûts aux dépends de la qualité a été de rigueur principalement.
     On a cru que des sociétés extérieures avaient des dons de clairvoyances, de voyances dans la gestion d’uen autre entreprise.
     L’informatique est un cas très spécial. Il y a trop d’échelons qui se sont ajoutés à la mise en route d’une application, ou même du plus petit changement.
     J’ai connu les deux époques. La première dans la souplesse et la rapidité.
     La seconde avec des gardes-fous à n’en plus finir.
     C’est entre les deux qu’il faut trouver le juste prix.
     Ce que tu dis, est exact.
     La fameuse pomme pour la soif, restée en background pour demander une prolongation des contrats.
     C’est aussi la non-recherche de la véritable raison d’une erreur.
     On prend plutôt sa grande sereingue et on crée un programme pour corriger la base de données en attendant une autre occasion pour recréer un autre programme.
     Tout cela, j’en avais des boutons.

    Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
• Par Halman (---.---.---.98) 11 décembre 2009 15:16

  

  J’oubliais, bien évidemment la direction de l’établissement oublie de faire la déclaration de fichiers à la CNIL, et on s’aperçoit au moment de l’installation du logiciels qu’on ne peut légalement pas copier les fichiers de l’ancien logiciel sur le nouveau...

  Que bien entendu on demande à une société autre de créer le logiciel et sa base de données dans un format bien sur incompatible avec celui de l’ancien logiciel, donc se retaper la saisie manuelle de toute la base de données de l’hôpital...

  Que la société du logiciel débarque sans prévenir pour installer son produit et bien sur le service informatique pas au courant doit gérer en direct live à l’arrache la configuration du réseau et des ordinateur pour l’installation de la chose...

  La routine quoi...

  Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
• Par spartacus1 (---.---.---.218) 11 décembre 2009 15:19

  

  Je travaille (enfin, dans une retraite active maintenant) depuis longtemps dans l’informatique (depuis 1963). Et durant tous ce temps là, ce fut exactement la même chose : délais et coûts non respectés.

  L’auteur parle de 4 causes. Moi, je n’en vois qu’une : le manque de formation et surtout le manque d’aptitudes à l’informatique d’une majorité des intervenants (majorité que l’on peut estimer à 50-60 %). Et ceci à tous les niveaux : direction qui a le niveau de culture informatique d’un enfant de 4 ans ; responsables info peu compétents et, partant, ne maitrisant pas grand choses, ils sont surtout préoccupés de ne pas faire de vagues pour ne pas perdre leur job ; les « praticiens », assez souvent sans formation sérieuse font ce qu’ils peuvent, c’est à dire pas grand chose, etc.

  La minorité compétente, est totalement noyée dans cet amas informe et ne peut pas faire grand chose. Alors elle s’amuse à réaliser de micro-projets qui l’intéresse mais qui n’ont que peut de rapport avec le projet de départ.
  J’ai vécu une carrière de 26 ans dans ce milieu, écrivant de petites applications personnelles qui m’amusaient, publiant dans des revues scientifiques (cela m’a permis de me faire un petit nom et, surtout, cela m’a été utile pour la suite de ma carrière dans l’enseignement), j’avais le temps, les tâches qui m’étaient imparties ne me prenait que 25 % de mon temps (comme cela aurait été le cas pour toute personne normalement compétente).

  Les dernières 20 années de ma carrière, je les ai passées à enseigner en école d’ingénieur, en espérant que mes paroles ne tomberaient pas dans des puits dans fond. Mais certains de mes ex-étudiants sont revenus me voir complètement désabusés par ce qu’il avaient trouvé dans la vie pratique. Je n’ai pu que leur conseiller l’attitude que j’avais eu moi-même.

  Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
  • Par sobriquet (---.---.---.88) 11 décembre 2009 20:33

    J’ai le même ressenti : sur un gros projet informatique, plus personne n’avait la maîtrise du code depuis plus de 6 mois. Le directeur de projet ne se préoccupait que des évolutions fonctionnelles et planifiait déjà les fonctionnalités qui devraient être présentes dans la version n+3. La moitié des développeurs avaient appris à programmer sur le tas, et étaient surtout occupés à résoudre manuellement les problèmes que le logiciel ne pouvait pas gérer.

    Comme le code était absolument inabordable (c’est une astuce de développeur pour être invirable), ils n’ont rien trouvé de mieux à faire que de demander à un intérimaire de reprendre la maîtrise du projet et coder les évolutions fonctionnelles urgentes.

    6 mois plus tard, l’intérimaire n’avait pas beaucoup avancé (cela étonne quelqu’un ?) ; lui et la maitrise du code qu’il avait accumulé ont remercié...

    Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
  • Par sobriquet (---.---.---.88) 11 décembre 2009 20:38

    Pardon, lire :

    « lui et la maitrise du code qu’il avait accumulé ont été remerciés... »

    Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
  • Par L’enfoiré (---.---.---.142) 12 décembre 2009 09:26

    

    Saortacus1,
     Belle carrière, 8 ans de plus que moi.
     Nous en avons vu de toutes les couleurs avec l’informatique, non ?
     Comme j’aime l’arc-en-ciel, j’ai aimé surtout au début.
     Période où tout était à créer.
     Vous dites délais et coûts depuis le début ?
     Pas sûr. Avant les budgets informatiques étaient bien plus importants et les contraintes imprécises trouvaient une compensation dans des délais acceptés plus élastiques.
     Le manque de formation ? Oui, mais vous oubliez les sables mouvants de cette formation.
     La manque d’aptitudes en découle.
     La direction, ce n’est que récemment qu’elle s’est intéressée au « comment c’est fait ».
     Je me souviens du manager financier qui avait un PC sur son bureau pour faire bien, et qui m’a apporté toutes la documentation qui l’encombrait.
     Vous n’avez pas dû connaitre pour avoir quitté avant, l’outsourcing offshore.
     Là, cela devenait carrément l’enfer pour ne pas perdre son job. 
     
     
     

    Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
  • Par L’enfoiré (---.---.---.142) 12 décembre 2009 09:28

    

    Sorry pour l’ortho de votre pseudo.

    Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
• Par Halman (---.---.---.98) 11 décembre 2009 15:41

  

  L’ex directeur de mon service informatique se mettait la honte dans les réunions parce qu’il n’était pas capable d’insérer sa clé usb dans son portable pour les projections de documents.

  C’était la directrice de l’hopital elle même qui se levait et le faisait.

  Celui là passait plus de temps à soigner ses relations et sa carrière que de s’occuper de son service.

  Ceux qui l’ont remplacé passent leur temps à parler ensemble et à s’engueuler.

  Alors nous on fait notre travail sans nous occuper de ces gens là. Quand on a un problème on s’adresse à notre ingénieur sans passer par la direction, même pour les simples commandes de matériel. Parce évidemment, on nous a supprimé la seule secrétaire du service... Les autorités s’imaginant que les secrétaire de l’autre hôpital à l’autre bout de Paris vont pouvoir s’occuper des tâches quotidiennes chez nous.

  Ce genre d’aberration est notre lot quotidien, alors quand on a une imprimante ou un client léger à remplacer, cela ne prend pas une heure mais une semaine. Parce que le gars du réseau ne considère pas comme urgent de me fournir une adresse ip par exemple...

  La direction générale informatique, ayant d’autres chats à fouetter autrement plus importants que nos petits logiciels de formations, fait trainer les bugs pendant des années, nous menant en bateau en répondant n’importe quoi aux emails de demande d’interventions.
  Un coup c’est notre réseau, une autre fois la base de donnée mal programmée, une autre fois il faut faire une enquete pointue dans tout l’hopital voir si ce ne sont pas les utilisateurs, ou bien localement le réseau, ou bien les pc à remplacer, et cela fait trainer et certaines parties de l’applications sont devenues inutilisables en formations.
  Les agents étant donc mal formés et pas au point dans les services de soins...

  Il est plus que temps de remettre les choses à plat.

  De faire retravailler tout le monde sur les mêmes bases, de virer ceux qui trouvent plus urgent de faire mumuse avec des gadgets de surveillance de réseaux et de sauvegardes (automatiques !) sous linux que de faire leur travail.

  Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
• Par HELIOS (---.---.---.87) 11 décembre 2009 16:11

  

  Puis-je a mon tour, experience et professionnalisme oblige, oser avancer un avis ?
  
  Je ne remets pas en cause, ni les 4 origines supposées par les auteurs, ni les autres « excuses » avancées par les divers intervenants.
  Je souhaite simplement souligner quelques points, pour alimenter cette discussion... un article de fond de plusieurs pages serait nécéssaire sinon !
  
  Donc, au dela de ce qui est dit, je voudrais raconter, parmi mes experience, celle d’un laboratoire d’analyse médicale. c’etait il y a deja pas mal de temps, bien sûr, une époque on on « faisait » encore des logiciels proprietaires pour cette activité.
  Pendant la conception, le soucis premier des « patrons » a été de faire développer un logicilel extrèmement rigoureux, comme le suppose l’activité, mais qui permettent beaucoup de souplesse.
  
  Il etait question donc de faire en sorte qu’on ne puisse pas identifier des « sequences » d’examens afin que les autorités ne puissent pas retrouver les dossiers payés... en liquide et non déclarés. «  »Vous comprennez, monsieur Helios, mes secretaires ne gagnent pas beaucoup, et je leur distribue pour les diverses vacances une somme qu’elle meritent bien«  ». Cela dit, les examens « cachés » devaient quand même ressortir dans les historiques medicaux...
  
  Ceci etait le cache misère d’une informatique qui devait prendre en compte une realité administrative ET humaine, les deux etant bien loin l’une de l’autre. Rapporté a ce qu’il se fait de nos jours, les conceptions les plus pointues, se heurtent regulierement a cette problematique. Les bases de données quelquefois bien simples, s’en trouvent subrepticement complexifiées, de même que toutes les procedures y accedant. La recette des travaux, s’appuyant sur des jeux d’essais, oh combien malins, ne reflete en aucun cas l’exhaustivité qu’elle devrait avoir. je vous laisse supposer de la suite, lors de l’usage et des pratiques au quotidien de tout ce qui a été développé et non testé.
  
  Bref, le non-dit et le non-ecrit sevissent beaucoup dans ce domaine.
  
  Par manque de temps, je ne m’appronfondirai pas sur d’autres deviances. Il y en a de nombreuses, liées a la conception même des systèmes d’informations, dans leurs composantes organisationnelles, réglementaire ou techniques. sur ces trois thèmes, mes 30 ans de carriere au plus haut niveau me permettrai de vous en raconter des vertes et des pas bien mûres comme on dit. Les demarches de conception, de developpement d’integration et d’exploitation ont toute des voies de contournement pour accelerer ou rentabiliser (selon du coté où l’on se place) la mise en place de cet outil fantastique qu’est « l’informatique »
  
  Les sociétés de service, comme les responsables des services informatiques, ont leur part de responsabilité... mais ces dernier temps, c’est plus l’incompetence généralisée qui rends si fragile une activité qui devrait être au dessus de toute les autres, question qualité. Cette incompetence est manifeste dans la majorité des entreprises productices de logiciel. Comment ne pas le constater quand on sait que les ingenieurs et les programmeurs sont sous payés, et virés des qu’ils ont plus de 5 ans pour les uns et 3 ans d’experience pour les autres. L’encadrement n’est pas non plus a l’abri de tout soupçon, la calcification des incompetences etant devenu une regle générale....
  
  a cette réponse, j’aurai pu vous en raconter sur :
  — la conduite du changement (sympa comme expression) qui permet de vendre un ingenieur tres cher de plus
  — la qualité... même remarque que ci-dessus
  — la formation... (les formations pourraient-on dire) qui dans 80% des cas donnent lieu a des contrats séparés, avec des petites entreprises dont le directeur de projet est comme par hasard associé...
  — les contrats liés sur les fournitures de consommables, de materiel, les entreprises de back-up etc cherchez bien, il y en a d’autres...
  --- j’arrete là, je n’ai plus trop le temps !
  
  Bonne soirée, demain, c’est le week end pour ceux qui ont la chance de bosser.

  Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
  • Par L’enfoiré (---.---.---.142) 12 décembre 2009 09:41

    

    Salut Helios,

     Cela fait du bien de relire les déboires que l’on a subi et que l’on retrouve partout.
     Une solidarité à posteriori dirions-nous. On dirait une réunion des anciens combattants. !!!
     Si vous allez lire ma Grande gaufre, vous allez comprendre où j’ai travaillé.
     D’abord en stand alone, subsidiaire par subsidiaire, machine à destination dans chacune d’elle.
     Puis, les machines ont mis les bouts. Centralisation oblige dans plusieurs sites privilégiés et puis retour à la case départ, au siège.
     Ensuite, ce furent les applications qu’il a fallu centralisée.
     Centraliser les applications ? Là, cela rigolait du coup, un peu moins.
     Les législations par pays, au niveau de la variété, on était servi jusqu’à en devenir avarié.
     Mais on gardait des antennes dans chacun d’eux, donc on gardait un contrôle.
     Rebelotte, nouveau tour de vis.
     Outsourcing, une société de ce type n’a pas les objectifs du clients. Ils sont même parfois totalement opposés.
     Offshore... aille.
     Voilà, l’anglais qui prend des formes inattendues.
     La culture n’en parlons pas.
     Là, on commence vraiment à tanguer.
     Les coûts que l’on a estimé pour les diminués, n’ont jamais été évalués par la suite.
     Peur probablement, de dégommer ceux qui ont été à la base du projet.
     Les gens qui ont vision à 360° du business, ou découragés ont pris les voiles depuis longtemps ou sont seuls bien payés par de simples règles de l’exclusivité.  

    Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
• Par Piotrek (---.---.---.242) 11 décembre 2009 16:41

  

  J’vais oser pousser le probleme plus loin :

  Il y a des tas de methodes (Waterfall, AGILE, Extreme Programming...) qui ont ete crees pour resoudre les problemes evoques dans l’article et les commentaires. Je crois que ces solutions ont explore la gamme de possibilites de modeles organisationnels hyperformels aux modeles d’organisations chaotiques pour un projet informatique. Et quoiqu’on fasse, les problemes surgissent.

  Il est impossible de changer l’homme et ses defauts ; Il est trop couteux de vraiement comprendre l’univers du marche dans lequel evolue le client pour faire ou ameliorer une solution informatique. Il est donc naturellement tres difficile de jauger un delai avec des informations parcellaires...

  Donc je me lance : le probleme dans les projets informatiques c’est pas l’homme, c’est la technologie elle-meme

  L’avenir reside dans une technologie ou chaque element est explicite par lui-meme (une genre de technologie naturellement semantique, qui devra etre comprehensible par le client lui-meme. Cette technologie sera transversale, ou lorsqu’on apporte une modification a un element particulier, tous les elements lies sont modifies en consequence de maniere trensparente mais evidente. Cette technologie sera a meme d’optimiser et de tester les modifications non seulement a la creation du projet, mais en permanence durant toute la vie du systeme.

  V’la ce que j’en pense

  Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
  • Par L’enfoiré (---.---.---.142) 12 décembre 2009 11:37

    

    Piotrek,

     Il y a beaucoup de logiciels qui permettent de « huiler » un projet.
     « Project » de MS n’est que l’un qu’on a utiliser. Il y a aussi la modélisation très sophistiquée.
     Le problème, c’est qu’ils ne sont pas intégrer avec les autres projets. Ils se terminent par un appel extérieur indéfini ou défini ailleurs.
     Ils ne tiennent pas compte aussi de beaucoup de facteurs humains.
     Dans le Open on cherche (ceci pour Morice)

     Nous avons en Belgique un logiciel appelé Georoute pour la Poste et les facteurs.
     Le but organiser les tournées au mieux.
     Nous en sommes je crois à la version 3, je crois, mais le facteur humain n’y est pas encore entré à suffisance. Ils s’en plaignent en permanence. Ils pourraient vous en parler.
     Quand l’humain tombe malade ou en indisponibilité, cela ne marche plus.
     Des réajustements en catastrophe.
     L’analogique n’a pas encore comblé la fracture avec le numérique.
     L’IA pourra peut être améliorer le processus. Wait and see.

     La théorie du 3D qui explicite les processus par les différents niveaux, pour expliquer la technologie. Peut-être ? Est-ce un autre oeuf de Colomb ?
     A condition qu’on trouve de lui casser la coquille sans faire trop de mal.
     

    Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
• Par Alain38 (---.---.---.100) 11 décembre 2009 16:48

  Quelques remarques additionnelles :
  1- un projet informatique est bien souvent un projet de type « recherche et développement ». De ce fait tous les paramètres sont souvent loin d’être connus avant le lancement du projet,
  2- lorsqu’on est prestataire pour un client, plusieurs paramètres entrent en ligne de compte :
  2-1. Ce qu’a « vendu » le commercial qui est bien souvent techniquement impossible dans les délais et l’enveloppe budgétaire définie,
  2-2. Ce que le client a estimé devoir être le coût du projet, et qui diffère bien souvent de l’estimation du futur prestataire,
  2-3 Le choix de la régie par rapport au forfait se justifie aussi par une raison simple. Un forfait nécessite de tout prévoir à l’avance, et de prendre ses précautions. De ce fait le coût annoncé au client peut le faire bondir. En régie c’est le client qui gère le niveau de qualité qu’il souhaite obtenir, ainsi que le planning et ses dépassements. C’est donc lui qui prend aussi bien le risque financier que le risque technique,
  3- Pour bien préparer son projet (donc avant même de parler planning, budget, etc), il faudrait y passer facilement un mois afin de bien baliser tant les problèmes et solutions techniques, que les besoin sur tous les niveaux. Quel client est prêt à attendre 1 mois qu’un prestataire lui donne un devis ? Quel prestataire est prêt à investir 1 mois de salaire d’un chef de projet sans aucune certitude d’obtenir le marché ?
  4- Dans TOUS les projets auquel j’ai participé il y a toujours eu deux parents pauvres : la documentation et la validation. Or c’est quand on va passer en validation qu’on va découvrir d’innombrables bugs que les tests unitaires n’auront pas révélé. Et qu’on va alors exploser le délai du projet. Et sans documentation la reprise du projet (avec une nouvelle équipe bien sur !) entrainera du travail de « reverse engineering » coûteux et approximatif.

  Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
  • Par french_car (---.---.---.23) 11 décembre 2009 21:01

    Si la qualité n’est pas au rendez-vous la SSII va trinquer pendant la période de garantie !

    Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
  • Par L’enfoiré (---.---.---.142) 12 décembre 2009 09:49

    

    Alain38,

    « le parent pauvre la documentation et la validation. »
    Je dirais 2 choses. La documentation, c’est surtout disons un problème humain, on n’apprend pas à faire une bonne documentation structurée. C’est vrai, il y a une série de niveaux, conception, construction, implémentation, « enhancements » et j’en passe.
    Le 2ème point et le plus important, c’est leur maintenance.
    Tout cela pourquoi ?
    Pour souvent se voir disparaitre après 2 ans d’expoitation parce qu’il y a une nouvelle lubie ou un nouveau soft que la direction a entendu parler.
    On passe au release suivant parce que la société ne maintient plus la version que vous utilisez.
    The show must go on.
    Ce n’est pas « Yes you can » c’est :
    « Do it. » ou « Imagine it done » (tiens c’est une vieille phrase utilisée qui me rappelle tellement de souvenirs) 
    

    Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
  • Par finael (---.---.---.53) 12 décembre 2009 11:28

    

    J’ajouterai que faire une bonne documentation cela prend du temps !
    
    Temps généralement compté comme du « gaspillage » par les chefs. Personnellement je me suis fait engu..... plus d’une fois, accusé de « perdre mon temps ».
    
    Une seule fois, il y a bien longtemps (putain bientôt 30 ans !) j’ai écrit (seul) toute une chaine de programmes ... pardon un « logiciel », et réalisé une documentation complète, à la fois technique et mode d’emploi. La chaîne a fonctionné dix ans (au moins) sans qu’il y ait une seule demande de support.
    
    Cela ne m’a, bien évidemment, strictement rien rapporté ... en fait on m’a changé de service.

    Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
  • Par L’enfoiré (---.---.---.142) 12 décembre 2009 15:24

    

    Finael,
     En fait, j’ai connu deux périodes de carrières.
     Au niveau local et au niveau international.
     Au niveau local, c’était la souplesse des mise à jour avec il faut l’avouer plus de risques (amis aussi plus vite corrigé)
     Au niveau international, c’est la lourdeur de l’implémentation qui s’installe par étapes avec outils workflow.
     Les demandes de support sont enregistrée, dès lors, dans des systèmes qui demandent un séries d’approbation par des gens chargés de le faire mais sans réelle connaissance des risques existants ou non.
     

    Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
• Par goc (---.---.---.37) 11 décembre 2009 18:47

  

  Pour moi, il y a surtout une cause principale, c’est incompétence des informaticiens

  il n’est qu’a voir les usines a gaz (visual studio, asp, et surtout .net) qu’on est obligé de créer pour avoir une chance qu’un programme ne se plante pas toutes les 30 secondes. Je suis effaré de voir certaines sources d’un verbiage démentiel. A croire que certains se regardent en train de programmer, ou pensent que la qualité d’un programme tient uniquement au nombre de ligne source

  et puis on sait depuis le début que ce n’est pas en mettant deux personnes sur un même projet qu’on va 2 fois plus vite. Il existe même un point ou tout ajout de personnel ne fait que ralentir le projet, et donc l’amener vers l’échec

  Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
  • Par finael (---.---.---.53) 11 décembre 2009 19:09

    

    C’est pas faux !
    
    Mais il n’y a pas plus d’incompétents chez les informaticiens qu’ailleurs, juste une majorité.
    
    Ca fait dix ans que je me suis entendu dire par l’APEC - rien que ça -, que "la compétence était un handicap

    Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
  • Par goc (---.---.---.37) 11 décembre 2009 19:30

    

    @finael

    Mais il n’y a pas plus d’incompétents chez les informaticiens qu’ailleurs, juste une majorité.

    d’accord avec toi
    le seul problème c’est que cette incompétence se retrouve à tous les niveaux et en même temps : aussi bien dans la programmation (pissage de lignes inutiles), dans l’analyse (manque total de logique), dans l’interfaçage (aussi bien en terme d’ergonomie qu’en terme de liaison inter-modules), dans le développement (aucun savoir-faire industriel, on est dans « l’artistique » le plus total et on en est fier) , et surtout dans la compréhension même des besoins du client (incapacité à se mettre à la place du client), et pour cause : on est informaticien et non comptable ou banquier, or comme en face on n’est pas informaticien, forcement on ne parle pas le même langage. seulement le client c’est l’autre donc a nous de nous mettre à sa porté, et non de le regarder de haut

    ps : quelle est la différence entre un terroriste et un informaticien ??

    - avec le terroriste, on peut toujours discuter !

    Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
  • Par finael (---.---.---.53) 11 décembre 2009 20:34

    

    Ingénieur système : être asocial et ne parlant qu’hexadécimal !

    Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
  • Par L’enfoiré (---.---.---.142) 12 décembre 2009 09:57

    

    Goc,
     Je vais vous donner un secret.
     L’informatique a attiré beaucoup de « laisser pour comptes » d’autres disciplines qui poussés par la pub, pensait gagner du pognon en masse.
     L’informatique, c’est un besoin d’un état d’esprit logique très spécial.
     Cela ne se trouva pas en dessous d’un sabot d’un cheval.
     Quand on aime et qu’on a compris, ce n’est plus travail, cemla devient un hobby.
     Les heures ne comptent plus.
     Programmer, c’est un job d’invention.
     Inventer, c’est cherché la meilleure approche à la résolution d’un problème ou comment le fusionner avec un autre avec des interfaces ou des liens en directs.
     Comment le découper ce projet tout en le gardant en vie le plus longtemps aussi.
     « Morceler il en restera toujours quelque chose » écrivais-je, un jour.
     C’est toujours vrai, mais pas n’importe comment.

    Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
• Par cerisier (---.---.---.116) 11 décembre 2009 20:46

  Pourquoi se mettre à deux pour rédiger un tel article ?

  
  

  La rivalité, la mesure, la logique de résultat et l’outillage présentés comme les principales causes d’échec d’un projet informatique c’est très original. Personnellement, aucune d’entres elles me seraient venues à l’idée. Il me semble que les causes principales les plus convenues dans le milieu sont du type :
  

  -expression du besoin vague

  -manque de communication

  -disponibilité des acteurs

  -réunionite

  -manque de méthodologie

  -manque de pilotage

  -livraison à l’heure au dépend de la qualité

  -sous-estimation des délais

  -...

  
  

  Cet article de « Christophe & Serge » me rappelle la série des Brother&Brother de Canal+.

  
  

  
  

  
  

  Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
• Par french_car (---.---.---.23) 11 décembre 2009 21:04

  Ce qui m’étonne c’est que personne n’ait parlé d’offshoring. Il me semble pourtant qu’on ne développe plus grand-chose en France et que les développeurs soient recrutés en Inde, au Magreb, au Vietnam ... Il ne sont pas moins compétents mais plus loin du besoin, et - pour les Indiens au moins - peu francophones ?

  Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
  • Par Alois Frankenberger (---.---.---.132) 11 décembre 2009 21:23

    

    Ce qu’il y a de bien avec les Indiens c’est que quand il y a un problème ils font un beau sourire - en visioconférence - et ils disent « No problem » !
    
    Méthode coué bien évidemment !

    Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
  • Par Marc Bruxman (---.---.---.68) 12 décembre 2009 01:32

    On ne parle plus d’offshoring car c’est un échec dans de nombreux cas. A part remplir du code à trous (qu’il faudra faire écrire par un vrai ingé ici) le développeur indien ne sert à rien. 

    Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
  • Par L’enfoiré (---.---.---.142) 12 décembre 2009 10:00

    

    french-car,
     Désolé, j’en parle un peu tard. Je prends le train en marche.
     Vous avez dit « Inde », bizarre comme c’est étrange....
     Si vous voulez un peu de cru dans le genre. « Symphonie indienne » devrait vous plaire.
     Ce n’est pas totalement tourné vers l’informatique d’ailleurs.

    Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
  • Par french_car (---.---.---.23) 12 décembre 2009 13:41

    Excellent article Guy.
    Cela fait plusieurs années que je travaille avec eux, je pense qu’on est perdants, parce-que tout ce qu’ils ne font pas, on le fait en amont et en aval. Le coût global de l’informatique s’en trouve réduit de quelques cacahuètes en contrepartie d’une fuite de savoir-faire et d’un risque important de turn-over de leur côté.

    Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
  • Par L’enfoiré (---.---.---.142) 12 décembre 2009 15:32

    

    Max Bruxman,

     « Un développeur ne sert à rien »
     En fait le problème n’est pas là. ( et j’en parle dans ma Symphonie indienne).
     Il y a comme partout des gens capables et d’autres un peu moins qui ne peuvent prendre des initiatives.
     Ceux qui sont les chefs de projets cherchent parfois la 25ème de la journée pour pouvoir comblé les retards et donner du travail à ceux qui dépendent de lui.
     Un Indien ne peut pas vraiment dire « non » à son client. Alors, parfois, il y a des drames, une mauvaise compréhension, (linguistique ou à cause de meeting par téléphone, conférence pour le transfert d’info.) et un développement qui ne correspond pas à ce qui est demandé, en finale.
     

    Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
• Par lerma (---.---.---.67) 11 décembre 2009 21:36

  

  Je donne mon expérience
  
  
  L’informatique à toujours été un veau d’or jusqu’ à la prise du pouvoir des budgets par les financiers
  
  On peut situé la fin de l’age d’or avec la 1ere guerre en IRAK (en dehors de l’euro et l’an 2000 ou l’obligation de basculer les applications était vitale pour la survie des entreprises)
  
  Les financiers ont pris le contrôle sur le budget informatique et n’ont eu comme objectif que de réduire le coût au plus bas car ils considèrent que l’activité première de leur entreprise n’est pas l’informatique et il oublient bien souvent que le coeur de l’entreprise c’est le système d’information et son personnel qui constitue une valeur ajouté en terme
  de disponibilité,performance et qualité du service.
  
  Alors comme il faut rester entre gens bien,les grosses SSII ont instauré des normes (ISOxxx) pour mieux vérouiller l’accès aux marchés de la prestation intellectuelle car ses normes représentent un cout financier important à maintenir et comme les appels d’offres des entreprises c’est d’avoir le beurre et l’argent du beurre,nous avons pu voir la mort des petites entreprises qui avaient des contrats en directes (aujourd’hui si elles existent elles sont sous-traitantes des grosses SSII,qui elles mêmes sont traitantes des clients !) et il est très rare de voir des petites structures avoir un référencement dans un grand compte
  aujourd’hui.
  
  Le coeur des systèmes d’information avaient bien souvent un MAINFRAME et bien souvent de marque IBM http://www.nsiservices.com/liferayportal/web/public/grands-systemes
  
  La logique primaire des financiers aura été de choisir l’option « système ouvert » car pour eux système ouvert=Unix=gratuit !
  
  Donc ,ils ont lançé des projets de destruction massive des systèmes d’information propriétaire et payant pour migrer des applications vers les systèmes ouverts en pensant éliminer la part des dépenses informatiques
  
  http://fr.wikipedia.org/wiki/Syst%C3%A8me_ouvert_(informatique)
  
  Seulement c’est une vision primaire ultra-libérale de la recherche de réduction de coût dans le seul but de satisfaire le court terme pour les administrateurs de l’entreprise ,car bien souvent il existe des couts cachés qui font exploser les budgets car le système ouvert ce n’est pas le système structuré et organisé en terme de production informatique qu’apporte le MAINFRAME.
  
  Bien souvent,les entreprises,quelques années après ,reviennent au Mainframe et je ne connais pas une seule banque qui soit full unix,le coeur reste le mainframe IBM.
  
  D’autres part en terme de sécurité ,le piratage est plus facile sur Unix que sur un système propriétaire inviolable car il est structuré et il est pensé en terme de sécurisation de données.
  
  La logique des financiers aura été de faire le développement (en C) dans des pays à bas cout comme le Maroc pour la France ou la Roumanie,mais cette logique est une logique suicidaire pour l’entreprise car elle n’a plus la maitrise de son système d’information que constitue son informatique (l’historique,la culture des compétences techniques licenciés...)
  
  Bref,cette logique devrait mourrir avec la crise financière ,qui je l’espere ne fait que commencer car plus elle sera meurtrière,mieux la situation sera assainie pour les futurs petites entreprises qui pourront proposer des services sans passer par des intermédiaires et les emplois ne seront plus délocalisés pour la recherche du cout le plus bas
  Les grosses SSII sont devenues des structures financières aux mains de fond de pension
  anglo-saxon en général (GFI,Cap..) et dont l’objectif n° 1 est de faire le maximum de profits au détriments de l’emploi en France
  
  Pour bien comprendre l’ampleur des échecs de projet informatique (généralement de migration,vous avez oublié de le signaler !) c’est l’opportunisme de petit malin que sont le directeur financier et le directeur informatique qui auront « vendus » cette idée au administrateur de l’entreprise
  
  Il est dommage,que les administrateurs ne puissent pas être poursuivi en justice pour crime économique car devant tant de destructions de richesses intellectuelles et de cultures informatiques Mainframe et donc d’emplois,ces gens devraient devoir rendre des comptes à la société
  
  L’informatique aura été un age d’or pour des centaines de milliers de personnes en France,aujourd’hui,après ces projets de migrations lancées voici quelques années ,le passif est désastreux en terme de cout caché et de destruction massive d’emplois
  
  Il faut avoir le courage pour un responsable d’entreprise ou un directeur informatique ou à des administrateurs d’une société ou d’un groupe d’arrêter un projet dont le coût par rapport à la qualité du service n’apporte qu’une REGRESSION
  
  Sinon,comment comprendre la logique de poursuivre dans la re-création d’un système d’information qui réinvente l’informatique des années 60 ???
  
  http://www.tvargentine.com
  
  
   
  
  
  
  
  
  
  
  
  

  Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
  • Par french_car (---.---.---.23) 12 décembre 2009 13:46

    Vous êtes noyauté par Big Blue vous ou quoi ?
    Effectivement les banques sont restées sur Mainframe, pour 2 raisons :
    - ce sont des machines puissantes et sécurisées
    - les applications sont ancestrales et leur migration totale vers UNIX serait risquée et couteuse
    Pour le reste l’industrie est en train de les abandonner et de migrer classiquement vers du 3 tiers, Oracle/Linux, Websphere/Solaris (vous voyez IBM n’a pas tout perdu) et applets Java sur client léger.

    Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
  • Par L’enfoiré (---.---.---.142) 12 décembre 2009 15:13

    

    Salut Lerma,
     Beaucoup de vérités.
     Le langage C ? Et l’assembler 360, n’avez-vous utilisé ?
     Si vous lisez ma conclusion, je ne dis pas autre chose.

    Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
• Par Atlantis (---.---.---.22) 11 décembre 2009 23:20

  

  http://www.atoute.org/n/local/cache...
  

  Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
• Par joelim (---.---.---.104) 11 décembre 2009 23:49

  

  Un dessin qui décrit succinctement la réalité du « Projet informatique » dans les années 80 : http://www.pyrat.net/sites/pyrat.ne...

  Je vois que çà n’a pas changé !

  Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
• Par Marc Bruxman (---.---.---.68) 12 décembre 2009 01:30

  Les raisons de l’échec c’est surtout du aux professionels incompétents que l’on met au management. 

  
  

  Des gens qui souvent n’ont jamais écrit une ligne de code de leur vie, se retrouvent manager, font mousser leur supérieur avec des idées irréalisables, se défaussent de leur responsabilité sur la première SSII venue (C’est pas moi j’ai confié le bébé à Alten vous comprenez !).

  
  

  Ce qui est un désastre, c’est cette idée que l’ingénieur doit être un manager avant d’être un technicien. Cette idée fait des ravages parce que du coup on nomme des « managers » qui n’ont aucune compétences techniques et le métier d’ingénieur n’a plus aucune raison d’être. 

  
  

  Franchement tant qu’à recruter un tel manager autant le prendre dans une école de commerce. Le jour ou les écoles d’ingés se sont crues devoir concurrencer HEC on a semé la graine de l’échec. 

  
  

  Et ce n’est pas prêt de se terminer. 

  
  

  Cela dit, quand vous avez votre diplome et des compétences techniques, c’est pratique. Avec un peu de doigté, cela se négocie très bien auprès des bons employeurs.

  Et sinon oui la SSII veut facturer du jour, c’est pour cela qu’elle est la. Mais si elle vous a blamé pour avoir fini un projet dans les temps, elle est stupide. Ce marché est très concurrentiel, alors la vrai façon de faire du beurre c’est le client fidèle. Mais ca aussi y’en a qui ont du mal à le comprendre. 

  Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
• Par Manfred (---.---.---.136) 12 décembre 2009 01:43

  

  Je suis tout à fait d’accord sur le constat des dépassements de délais imposés pour la fabrication des logiciels, ainsi que sur la qualité des logiciels en général.

  Seulement, il faut comprendre plusieurs choses :
  - Le travail de l’informaticien n’est pas mécanique, il créé en permanence. Quand on est confronté à la création, il est pratiquement impossible de dire quand la finalité de l’oeuvre pourra être atteinte. C’est comme demander à un peintre un délai pour lequel son tableau doit être achevé, en respectant telle ou telle couleur etc... Qu’on le veuille ou non, on ne peut pas prédire le temps pour faire une invention, un logiciel, sinon, c’est déjà ne plus inventer. Or, en informatique, tout existe, et rien à la fois, chaque ligne de code qui est écrite est censée ne pas exister préalablement.
  - L’informatique a très bien évolué ces dernières années. Et on voit notamment que le métier de l’informatique prend de plus en plus en compte une phase d’analyse. Seulement, ça demande bien des efforts très conséquents et qui ne peuvent être quantifié. Analyser c’est prévoir, architecturer un logiciel, avant même de le créer.
  - En informatique on aura beau prédire tous les délais qui soient, nous sommes plus que quiconque confrontés à des situations de crise. Des situations de crises sont tous les imprévus, coupure d’électricité, défaillance du matériel, changement de système d’exploitation, formatage d’un disque dur, sans parler des crises imposées par les personnels eux-mêmes... Ces crises là ne sont pas prévisibles. Seule l’expérience personnelle permet de tomber au mieux dans les délais établis. Un logiciel ce n’est pas une recette qu’on applique comme on ferait un gâteau : cuire 5 minutes, régler sur thermostat... Faire un logiciel c’est inventer une nouvelle recette à chaque fois.
  - Les coûts engendrés par les salaires pour payer un logiciel sont extrêmement faibles. Ca ne doit même pas représenter 1%. Quand vous achetez un logiciel comme un système d’exploitation microsoft, vous ne payez pas les salaires des développeurs, vous payez des gens qui veulent leur part du gâteau et qui en profitent pour continuer d’exploiter le filon.

  Je dirais qu’il y a plusieurs faces de l’informatique :
  - Les personnes qui n’y connaissent rien mais qui veulent en profiter et qui croient que ce service est comme n’importe quel autre service, donc auquel il faut réduire toujours plus les coûts et les délais. En faisant cela, ils n’ont plus qu’à aller développer en Inde (ce qu’ils font d’ailleurs), et pour les logiciels de qualité ils repasseront.
  - Les développeurs qui ont la pression, et qui sont sous-payés, alors que s’ils ne faisaient pas leur travail, personne ne pourrait le faire à leur place, et personne ne pourrait se faire des montagnes de sous sur leur dos. Les développeurs ont tous les atouts en mains pour s’imposer, mais se laissent exploiter.
  - Les personnes qui achètent un logiciel et qui pensent que les développeurs ne font pas leur travail, et qu’on les paye trop cher, quand ce qu’ils achètent ne fonctionne pas, ou est tout simplement trop onéreux.

  Ce qu’il faut regarder, c’est la logique de la société de consommation, et les multinationales qui s’enrichissent bon gré malgré.

  Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
  • Par L’enfoiré (---.---.---.142) 12 décembre 2009 10:16

    

    salut Manfred,
     Ce que vous dites est très vrai.
    - La création, cela ne se commande pas.
     Un article anodin sur le sujet et pourtant...
    - Faire un planning d’un projet, qui le fait et selon quels principes ? Une question primordiale ?
     
    - l’évolution est importante, mais elle a été rattrapée par la complexité.
    La convivialité, la « beauté du show » se sont immiscé pour faire vendre une application. On approche d’autres jobs actuellement dans le design. L’analyse, c’est parfois 50% d’un projet. Visiter les futurs utilisateurs dans le monde et j’en passe.

    - Les crises ? Absolument. C’est ce dont je parlais des « différents acteurs intermédiaires ». La peur de se voir virer, croyez-vous que cela motive ?
    On veut le beurre, l’argent du beurre et le sourire de la crémière, aujourd’hui.

    Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
• Par L’enfoiré (---.---.---.142) 12 décembre 2009 08:37

  

  @L’auteur,

  Moi qui ai connu cette histoire et les développements mathématiques depuis 40 ans, c’est dire que votre article m’a intéressé.

  Je l’ai d’ailleurs appelé dans un ebook « La Grande Gaufre »).

  « Echecs, désastres financiers et humains »

  En fait, c’est vrai et ce n’est pas vrai. Vrai au départ, faux à l’arrivé.

  Un projet réussi n’est pas une exception mais il n’a pas le temps de murir.

  C’est çà le problème majeur. Ou business évolue en parallèle, change et quand le projet informatique est sur pied, il est déjà dépassé, ou s’est le logiciel utilisé qui se trouve déjà à une version ultérieure et qui nécessite une remise à niveau scolaire.

  Quel est le concepteur qui peut avoir une vue à 360° et une vue sur l’avenir ?

  Ce n’est que deux raisons qu’un projet patine. L’évolution du business est la grande raison des délais dépassés. Un cahier des charges suffisamment complet qui manque en est une autre. Depuis le début du siècle, c’est la sécurité qui a été poussé à l’extrême suite à Enron qui a mis des batons dans les roues.
  Suite dans mon ebook.

  Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
  • Par finael (---.---.---.53) 12 décembre 2009 11:19

    

    Salut l’enfoiré !
    
    Tu oublie aussi les projets jamais terminés :
    
    Quelque reponsable a une idée « brillante » et l’on décide de la mettre en application.
    
    Bien entendu, le responsable en question n’y connaissant rien, il n’a aucune idée des limites, des coûts, voire même de la possibilité de mettre en place son idée.
    
    Alors on lance une équipe sur le projet, équipe qui doit d’abord apprendre la nouvelle méthode employée (forcément meilleure puisque c’est dit dans les revues).
    
    Les semaines, les mois passent où l’équipe cherche à faire coller ses programmes à la méthode employée ... en général ça ne passe pas !
    
    D’autant plus qu« on » a décidé de rajouter ci et ça, de supprimer ceci ...
    
    C’est alors qu’un nouveau « responsable » arrive. Il doit se démarquer de son prédécesseur aussi décide-t-il d’employer telle autre méthode.
    
    Evidemment l’équipe de développement doit tout adapter, souvent modifier ses programmes.
    
    Au bout du compte on se retrouve avec des gens errant dans les couloirs, attachés à un projet qui ne verra jamais le jour car depuis on a décidé de changer d’OS, ou d’employer les machines de la nouvelle société qu’on vient d’acheter, ...

    Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
  • Par L’enfoiré (---.---.---.142) 12 décembre 2009 11:43

    

    Salut Finael,
     Je l’ai souvent dit, l’informatique, ce n’est pas une affaire dont on parle sur un coin de table ou avec un seul article.
     Je complète encore aujourd’hui mon eBook. Je ne choisirais jamais la forme statique de bouquin pour décrire l’« affaire ».
     Les projets sont parfois mort-né. J’en ai connu et pas des minces.
     Les hommes qui ne font que passer, c’est aussi une affaire très peu numérique.
     Pléthore de solutions, politiques fait aussi ralentir les projets les mieux préparés.

    Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
• Par Lucrezia (---.---.---.51) 12 décembre 2009 08:47

  Le problème majeur en France tient à ce que l’on ait voulu calquer un modèle mode projet Américain sur des structures d’entreprise Françaises encore hiérarchiques alors même que cela ne peut marcher qu’avec un modèle fonctionnel, seul modèle d’entreprise aux USA ...

  Gare au « Copier/Coller » !

  Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
• Par morice (---.---.---.242) 12 décembre 2009 10:36

  

  99% des projets reposent sur du Windows : ne cherchez pas plus loin le dépassement en tempss et en coût : réussir à faire causer ensemble 2 PCs relève déjà de la prouesse, alors pensez-donc pour un serveur et ses postes reliés c’est de l’ordre du magicien d’Oz...

  
  

  l’autre erreur est le développement : souvent, on fait développer une application... qui existe déjà dans le commerce mais qui n’est pas utilisée faute soit de connaissance soit faute de vouloir faire dépenser davantage : en base de donnés c’est très, très net... Ce sont les développeurs qui tuent les 3/4 du temps les projets informatiques. Ajoutez-y une merde telle que Vista et ça devient parfait.

  
  

  Aujourd’hui, en raison de l’échec de Vista, on installe des bidules dépassés sous XP : c’est à se marcher sur la tête !! on travaille avec un bidule de 8 ans d’âge : si en informatique une année en vaut 50, on a donc 4 siècles de retard...

  http://www.clubic.com/actualite-293...
  

  
  

  Si les écoles s’équiperaient de systèmes Open, les futurs développeurs ou chefs de projet résonneraient Open : or ce n’est pas le cas, les écoles sont pleines de Microsfot et RIEN d’autres !! le mal est là, à l"origine !!!

  Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
  • Par L’enfoiré (---.---.---.142) 12 décembre 2009 11:02

    

    Morice,
     Désolé, mais c’est faux dans l’entreprise.
     Microsoft n’a pas de pas de réel opposition à Oracle financial. ERP vous devez connaitre.
     Ce n’est pas uniquement le PC dans les entreprises. Ce sont des serveurs.
     Le magicien d’Oz a résolu le problème. Pour le monde entier et l’explotation, on avait 2 serveurs. (plus tous les autres pour les tests, bien sur).
     
     « Développer une application qui existe »
     Mais sans oublier les customisations qui ne sont pas piquées des vers, je vous assure.
     Espérer avoir une modification dans un temps précis, essayez et vous verrez.
     J’ai connu. Je peux vous en parler.
     Donc, il faut construire localement.
     Il n’y a aucun standard qui tiennent la route dans le monde entier.
     Vista, c’est quoi ?
     Open, please, don’t disturb.
     
     

    Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
  • Par pingveno (---.---.---.14) 15 décembre 2009 17:33

     Microsoft n’a pas de pas de réel opposition à Oracle financial. ERP vous devez connaitre.
     Ce n’est pas uniquement le PC dans les entreprises. Ce sont des serveurs.
    
    Ah bon tu fais les développements directement sur les serveurs toi ? Ou on te crée un « serveur de dev » et tu fais tes développements dessus ?
    En plus l’utilisateur final n’a généralement que faire du côté serveur de l’application, il ne voit que le côté client... qui de plus en plus souvent est une appli web (les clients lourds ça n’a plus la cote) qui doit supporter les contraintes de Internet Explorer version 4 ou inférieure.

    Soyons réalistes, la plupart des développements aujourd’hui c’est, pour des raisons purement marketting, tout le monde avec Eclipse sous Windows pour ensuite déployer sur un serveur Sun qu’on ne verra jamais, mais au final une appli Java/J2EE qui doit tourner sur IE4.

    Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
  • Par pingveno (---.---.---.14) 15 décembre 2009 17:37

    en base de donnés c’est très, très net...
    
    C’est le cas de le dire. En fait tu aurais dû écrire 99% des projets reposent sur du Windows pour le développement et la partie client, Oracle 9 ou 10 pour la base de données, J2EE + Spring + Hibernate.

    Si les écoles s’équiperaient de systèmes Open, les futurs développeurs ou chefs de projet résonneraient Open
    
    En tant que développeur je connais bien mieux Linux mais on me fait bosser sous Eclipse Windows, pas le choix. Et le chef de projet fait ce que le client dit, point final. C’est le client final qu’il faut convaincre, pas le chef de projet dont le rôle est de gérer le planning, pas la méthode.

    Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
• Par non666 (---.---.---.218) 12 décembre 2009 10:46

  

  La logique « projet » avait historiquement un but : donner un nom, un debut , une officialisation a un investissement, une remise a niveau.
  Petit à petit il est devenu avec la logique des profit center, un moyen de preciser ce qui coute quoi dans la marche permanente de l’entreprise vers la maitrise de ses couts.
  Or de simple instrument de mesure, il est devenu avec l’externalisation , un moyen d’imposer des baisses a ses fournisseurs.
  Ne pouvant pas faire baisser les salaires de LEURS salariés, en particulier dans cette industrie informatique a haut niveau de competence, les grandes entreprises ont tout simplement decider de mettre de plus en plus la pression sur les « acheteurs » pour faire baisser le cout informatique par tous les moyens.
  Le projet , comme le soutien informatique est donc prié d’offrir le meme niveau de gain de productivité annuel que l’achat de bien materiel produit en chine....
  
  Meme logique, meme effet.
  Comme les emplois a bas cout, la feminisation puis l’immigration ont vite fait leur apparition pour tenter de maintenir de l’activité « chez nous ».
  Maintenant , inexorablement, la meme logique que celle de l’industrie s’impose : il faut « delocaliser » puisque meme le tiers monde importé chez nous ne garanti plus ces baisses de cout attendues...
  
  Si vous voulez un service, un objet , un projet qui coute X chez nous a 0,5 X, vous etes bien obligé d’aller la ou il coute ce prix la.
  Les commerciaux, obsedés par la pression des clients acheteurs et de leurs employeurs qui te,ntent de survivre ne se rendent meme plus compte depuis longtemps qu’ils nous amenent lentement vers l’inevitable baisse des salaires pour tous.
  

  Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
  • Par L’enfoiré (---.---.---.142) 12 décembre 2009 11:16

    

    Non666,
     Absolument. « Tout pour rien ou rien pour tout »

    Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
• Par kasko (---.---.---.204) 13 décembre 2009 19:07

   

  Une cause majeure autre

  J’ai vécu beaucoup de projets informatiques et sous différents angles. J’ai été successivement développeur (programmeur puis analyste), chef de projet informatique, manager d’équipes informatiques (développement, systèmes, réseaux et exploitation), manager d’équipes utilisateurs (gestion de production) puis consultant en organisation et management (auprès des assurances et des banques). Ces expériences nombreuses et variées m’ont conduit à un diagnostic différend de tout ce qui a été écrit ci-dessus :

  la cause majeure est la prolifération incontrôlée des besoins des utilisateurs ou des clients.

  
  

  Rares sont les efforts pour se limiter aux besoins réels et justifiés. Les seuls projets que j’ai vu réellement sous contrôle – délai et coût – étaient ceux où les utilisateurs avaient au préalable réfléchi à ce dont ils avaient vraiment besoin. Contrairement à ce que prévoyaient certains sceptiques, ces utilisateurs se sont montrés très satisfaits lorsque ces applications ou ces systèmes sont devenus opérationnels. Pour arriver à cela, il a fallu aider les utilisateurs à imaginer leur mode de fonctionnement « idéal », donc à faire de l’organisation, sans parler à ce stade de solution informatique, puis de leur faire exprimer leurs besoins en termes de fonctions, pas en termes de solution informatique. Les informaticiens intervenant ensuite pour proposer des solutions techniques et les faire amender ou valider par les utilisateurs. Cela paraît simple, mais c’est rarement fait correctement. L’usage courant est plutôt de choisir a priori la solution informatique (développement local, progiciel, micro portable relié par liaison 3G,...), puis de chercher l’organisation adéquate lors du démarrage. Ca ne marche pas !

  J’ai en tête plusieurs exemples d’échecs patents confirmant cette analyse. A l’inverse, j’ai l’expérience de projets informatiques remis sur les rails en s’attaquant aux besoins utilisateurs sans remettre en cause le fonctionnement de l’entreprise et les apports de l’informatique. Une anecdote révélatrice : en tant que consultant, un DG me remercie d’une telle action et me demande qui de l’informatique et des utilisateurs il doit réprimander ; réponse : « les deux, les utilisateurs parce qu’ils demandent tout ce qui leur passe par la tête sans réfléchir à leur manière de travailler et l’informatique parce qu’elle joue les supermans en acceptant tout ».

  J’ai contasté que les informaticiens sont généralement capables de réaliser des projets dans les temps et dans les coûts prévus si le besoin est « raisonnable ». Leur problème majeur est la surestimation de leurs capacités due à une confiance excessive dans les évolutions technologiques, dans les nouveaux outils et dans les dernières méthodes. Ils ne savent pas dire « non », ils ne savent pas exiger qu’il y ait une phase d’analyse organisationnelle avant leur intervention.

  Plus globalement, le problème n’est pas de nature technique mais managériale, il est du ressort des dirigeants : directeur informatique, directeurs utilisateurs, directeur de l’organisation et directeur général, voire président.

  Kasko

  
  

  Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
• Par pingveno (---.---.---.14) 15 décembre 2009 17:44

  - La rivalité : en devenant une pratique majeure de management, le projet devient un terrain de conflit où les enjeux politiques, personnels, financiers s’affrontent ouvertement. Cette rivalité concerne aussi bien les acteurs internes de l’entreprise que tous les fournisseurs concernés. Il va s’en dire que cette rivalité se fait au détriment de l’entreprise.

  Je connais même pire : les projets qui n’existent que pour permettre à une personnalité de justifier son budget auprès de ses supérieurs et de tirer toute la couverture à elle en cas de réussite.
  Evidemment nous autres développeurs n’y avons pas notre mot à dire.
  
  

  - L’outillage : les entreprises se sont équipées en outil de gestion et de pilotage de projet, voire de gestion de portefeuille de projets. Cette automatisation du pilotage s’est réalisée au détriment du développement d’un management humain.

  Curieux, moi je n’aurais pas parlé d’outils mais de méthodes. Ces derniers temps on nous bassine avec des trucs Agile, et accessoirement pour donner l’illusion d’une méthode très technique, une pointe de Merise et un zeste d’UML.
  Jusqu’au moment où il devient plus important de respecter la méthode à la lettre et de cocher toutes les cases que d’avoir au final un logiciel qui fonctionne.
  

  
  

  Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
  • Par pingveno (---.---.---.14) 15 décembre 2009 17:46

    Je connais même pire : les projets qui n’existent que pour permettre à une personnalité de justifier son budget auprès de ses supérieurs et de tirer toute la couverture à elle en cas de réussite.

    Ah j’oubliais : jusqu’au jour où la personne part, le projet part à la poubelle et le remplaçant commande un nouveau projet tout beau tout neuf.

    Je vous jure c’est du vécu.
    

    Réagir à l'article Réagir à ce message Signaler un abus Lien permanent
• Par lesdiguières (---.---.---.236) 17 décembre 2009 18:35

  

  Bonjour à tous et à chacun,

  Le sujet est sensible et j’ai comme beaucoup de lecteurs assidus contribué au sabordage de nombreux projets de grandes envergures compte tenu de tout ce qui a été développé sur le sujet dans le cadre de cet article. J’ai terminé ma glorieuse carrière en qualité de consultant expert sur le fameux et presque incontournable système SAP. Maintenant à la retraite, j’avais envisagé de faire un « papier » sur les causes de ces échecs, puis l’idée est passée. La lecture de cet article m’incite à reprendre le stylo, car bien que tout ce qui a été dit est vrai, il me semble nécessaire d’enfoncer le clou sur des points bien précis. Je reviendrai donc avec ma perception du problème. Mais en attendant, j’invite les lecteurs qui sont pour la plupart des informaticiens chevronnés à lire sur mon blog un livre qui relate mes débuts dans cet univers impitoyable, il y a déjà là matière à réflexion, ...

  Titre du livre : Mes années 360 (360 pour IBM 360)

  http://lesdiguieres.blog4ever.com/b...

  Bonne lecture

  Henri
   

  Réagir à l'article Réagir à ce message Signaler un abus Lien permanent

Ajouter une réaction

Pour réagir, identifiez-vous avec votre login / mot de passe, en haut à droite de cette page

Si vous n'avez pas de login / mot de passe, vous devez vous inscrire ici.