Developpez.com - DI/DSI Solutions d'entreprise

Le Club des Développeurs et IT Pro

Pourquoi les projets de développement échouent-ils ? 92 % des développeurs et architectes de logiciels accusent la complexité~? le coût et les risques élevés associés à ces projets

Selon vFunction

Le 2022-06-23 17:09:23, par Sandra Coret, Communiqués de presse
Pourquoi les projets de développement échouent-ils ? Et peut-être plus important encore, qu'est-ce que les cadres supérieurs doivent comprendre sur les raisons de ces échecs ? Ce sont les questions auxquelles une nouvelle étude de la plateforme d'IA vFunction se propose de répondre.

Basée sur une enquête menée par Wakefield Research auprès de 250 développeurs et architectes de logiciels américains, à un niveau supérieur dans des entreprises de 5 000 employés ou plus, elle examine les différences d'objectifs, de défis et de raisons d'échec entre les chefs d'entreprise et les architectes.

Alors que 92 % des répondants prévoient de moderniser leurs applications ou sont en train de le faire, l'étude révèle que les projets de modernisation se sont avérés complexes, coûteux et risqués. Quatre responsables des logiciels et de l'architecture sur cinq déclarent qu'un projet de modernisation des applications a échoué en cours de route, et 74 % des personnes interrogées affirment que le projet type de modernisation des applications coûte plus d'un million de dollars, avec une moyenne de près de 1,5 million de dollars.

Au-delà du coût financier élevé, le temps est un facteur important. 58 % des responsables des logiciels et de l'architecture affirment que l'effort type de modernisation des applications prend plus d'un an, avec une moyenne de 16 mois par projet, et plus d'un quart (27 %) disent que cela prend deux ans ou plus.

L'un des principaux problèmes est que les luttes organisationnelles internes et le manque d'harmonisation entre les équipes commerciales et technologiques mettent en péril les efforts de modernisation des applications avant même qu'ils ne soient lancés, au point que 97 % d'entre eux prévoient que quelqu'un dans leur organisation repoussera un projet proposé. 43 % des personnes ayant connu des échecs dans le domaine de la modernisation des applications attribuent ces échecs au fait que les attentes n'ont pas été correctement définies, tandis que 37 % d'entre elles les attribuent aux changements de structure organisationnelle nécessaires.


Les architectes logiciels, quant à eux, citent le "manque d'outils intelligents" comme la première cause d'échec. La lutte contre les outils inefficaces et les compétences et la formation nécessaires pour moderniser est un thème commun aux architectes interrogés, car "trop complexe", "compétences ou formation inadéquates" et "incapacité à définir correctement les attentes" sont tous trois à égalité pour la deuxième raison la plus fréquente d'échec.

"Étant donné le coût et la durée de ces projets, il est essentiel de comprendre pourquoi ils sont réussis et pourquoi ils échouent ; l'enjeu est important. L'étude révèle que le coût, le risque et la complexité sont tous des obstacles reconnus aux projets de modernisation et que "lever et déplacer" n'est plus considéré comme un résultat de modernisation réussi", dit Moti Rafalin, PDG de vFunction. "Les architectes sont parfaitement conscients des avantages commerciaux de ces projets pour l'entreprise et ont besoin que la direction comprenne pourquoi les projets de modernisation des applications échouent. Ils ont besoin de la C-suite pour aligner et former l'équipe au succès et aider à construire l'analyse de rentabilité nécessaire pour obtenir le budget et les ressources nécessaires. Plus important encore, les architectes ont besoin d'outils intelligents pour leur travail."

Source : vFunction

Et vous ?

Trouvez-vous ce rapport pertinent ?
Quelles sont, selon vous, les principales causes de l'échec d'un projet ?

Voir aussi :

F5 révèle les avantages liés à l'accélération de la transformation numérique : les entreprises abordent la complexité avec des solutions d'IA et de SRE, et concilient modernisation et sécurité

AWS Mainframe Modernization, le service de migration des charges de travail mainframe vers le cloud, est disponible, des analystes redoutent que la dette technique finisse par vous rattraper

Pour une entreprise sur quatre, la moitié des projets d'IA échouent, d'après les résultats d'une enquête d'IDC
  Discussion forum
22 commentaires
  • Refuznik
    Membre éclairé
    Désolé, un peu vieux mais toujours d'actualité à ce que je vois.

  • smarties
    Expert confirmé
    Quelles sont, selon vous, les principales causes de l'échec d'un projet ?
    - trop d'ambition de livrer tout d'un coup plutôt que de livrer les fonctionnalités au fur et à mesure
    - délais trop courts, budget trop serré, client radin qui a sous-estimé le coût du logiciel
    - la complexité et ça se voit avec les offres d'emploi, les sociétés cherchent des développeurs qui maîtrisent tout la partie DevOps et ne veulent pas dédier la partie CI/CD à une personne tierce qui ne ferait que ça (les CDD et les freelances spécialisés ça existe !). Je vois régulièrement des missions avec la stack suivante : Python, Django/Flask/FastAPI, PostgreSQL/MongoDB/..., React/Vue.js, Jenkins, Docker, Kubernetes, AWS/GCP/Azure/..., RabbitMQ, GraphQL, échanger avec le client pour les besoins, anglais courant (et pas que technique)
    ... pour des salaires pas extraordinaires non plus
  • Anselme45
    Membre extrêmement actif
    Quelles sont, selon vous, les principales causes de l'échec d'un projet ?

    Ben, cela dépend de qui répond à la question...

    Pour le client ou le manager, c'est le développeur qui est nul...

    Pour le développeur, c'est le client qui ne sait pas ce qu'il veut et le manager qui ne sait pas gérer un projet...
  • Les projets de développement échouent parce que trop de personnes différentes ont voix au chapitre, entre les commerciaux, les chefs de projet, le référent technique chez le client, son chef, le corporate IT manager, etc...
  • d_d_v
    Membre éprouvé
    Vu le management toxique en place dans beaucoup d'entreprises, et le principe de Peter qui fait que plein d'incompétents se retrouvent dans des postes de décision, ça ne m'étonne pas que les projets échouent.
  • kain_tn
    Expert éminent
    Envoyé par Jeff_67
    Les projets de développement échouent parce que trop de personnes différentes ont voix au chapitre, entre les commerciaux, les chefs de projet, le référent technique chez le client, son chef, le corporate IT manager, etc...


    J'ajouterais:
    • Les équipes de ventes qui vendent des délais/coûts intenables sans même avoir une idée de la complexité d'un sujet. Quand ça commence par un "rétroplanning", on sait en général que le projet a de grandes chances de faire un four.
    • La direction qui ne sait pas faire de stratégie et qui change d'avis tous les quatre matins
    • Le management qui fait du micromanagement et qui se mêle des choix techniques (architecture, sécurité, stack technologique, etc)


    On a là toute la recette pour un beau gâchis quand toutes ces conditions sont réunies! Et d'ailleurs, ça ne se limite pas aux projets de développement, mais à un petit peu toutes les industries...
  • jpouly
    Membre confirmé
    Heuuuuuu, les spec...

    J'ai bon ?
  • TotoParis
    Membre expérimenté
    Pour voir ce rapport il faut donner des informations personnelles. Donc je ne lirai pas ce rapport, faut pas pousser.
    C'est quoi une "C-suite" ???
  • totozor
    Membre expert
    Etant plutôt coté client je pense qu'il y a aussi des gros problème avant le projet:
    Les clients ne savent pas écrire le cahier des charges de ce genre de projet.
    Certains managers "accompagnent" les clients pour l'améliorer mais le gonflent pour donner (et facturer) plus au client avec des besoins "faciles à mettre en place".
    Comme il n'y a pas forcément de gens techniques coté client, on se rend compte plus tard que ces besoins n'existent pas.
    Comme il n'y a pas forcément de gens techniques coté dév, on se rend compte plus tard qu'ils ne sont pas du tout si faciles à mettre en place.

    A la fin on se retrouve avec un client qui se plaint d'une solution qui ne sort pas à cause d'une chose inutile, et de fournisseurs qui se plaignent qu'on ne veut pas leur payer ce qu'il ne nous ont pas encore livré.
    Et on ne sait pas ce qu'il se passe entre le manager et les dev mais ça ne doit pas être reluisant.
  • esperanto
    Membre émérite
    Envoyé par smarties
    - la complexité et ça se voit avec les offres d'emploi, les sociétés cherchent des développeurs qui maîtrisent tout la partie DevOps et ne veulent pas dédier la partie CI/CD à une personne tierce qui ne ferait que ça (les CDD et les freelances spécialisés ça existe !). Je vois régulièrement des missions avec la stack suivante : Python, Django/Flask/FastAPI, PostgreSQL/MongoDB/..., React/Vue.js, Jenkins, Docker, Kubernetes, AWS/GCP/Azure/..., RabbitMQ, GraphQL, échanger avec le client pour les besoins, anglais courant (et pas que technique)
    Eh oui, les managers considèrent que plus un projet est complexe meilleur il est. Résultat, tu veux démarrer une appli Angular, t'as à peine tapé "ng new" que ton projet a déjà 150 dépendances d'un bon méga chacune. Pareil en Java, avant même la première servlet t'as déjà une vingtaine de jars (et en plus dans le git, beurk) plus une couche DAO, une couche services, une couche client, une couche business et j'en oublie probablement encore trois ou quatre. Ensuite on fait un copier-coller de tout ça une trentaine de fois et on appelle ça un micro-service...

    Envoyé par lvr
    1) Impliquer le client (et qu'il participe) à une véritable réflexion autour de cette modernisation.
    Impliquer le développeur aussi, pas seulement les "analystes" qui te pondent des specs immondes à prendre au pied de la lettre.

    Envoyé par lvr
    Répliquer les processus-métiers d'il y a 10 ans avec une nouvelle technologie n'a aucun sens.
    Ah si seulement mon client pouvait lire ça... Parce qu'actuellement la politique c'est: on achète le plus gros produit du marché et ensuite les développeurs ne font que de l'intégration coûte que coûte, en multipliant au maximum le nombre de couches d'abstraction inutiles juste pour que l'ancien workflow ait encore une chance de fonctionner...

    Envoyé par Jeff_67
    entre les commerciaux, les chefs de projet, le référent technique chez le client, son chef, le corporate IT manager, etc...
    Donc, pour la plupart, des gens qui n'ont jamais codé plus qu'un hello world dans leur vie (je note l'absence des développeurs dans ta liste). Les devs, ils sont juste là pour suivre les specs et servir de bouc émissaire si elles étaient mauvaises dès le départ.