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

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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 , par Sandra Coret

32PARTAGES

9  0 
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

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Refuznik
Membre éclairé https://www.developpez.com
Le 27/06/2022 à 9:16
Désolé, un peu vieux mais toujours d'actualité à ce que je vois.

17  0 
Avatar de smarties
Membre expert https://www.developpez.com
Le 24/06/2022 à 10:09
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
15  0 
Avatar de Anselme45
Membre extrêmement actif https://www.developpez.com
Le 24/06/2022 à 11:49
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...
14  0 
Avatar de
https://www.developpez.com
Le 26/06/2022 à 20:11
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...
10  0 
Avatar de d_d_v
Membre éprouvé https://www.developpez.com
Le 27/06/2022 à 9:54
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.
8  0 
Avatar de kain_tn
Expert éminent https://www.developpez.com
Le 26/06/2022 à 22:04
Citation Envoyé par Jeff_67 Voir le message
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...
7  0 
Avatar de jpouly
Membre confirmé https://www.developpez.com
Le 26/06/2022 à 23:14
Heuuuuuu, les spec...

J'ai bon ?
7  0 
Avatar de TotoParis
Membre expérimenté https://www.developpez.com
Le 25/06/2022 à 21:18
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" ???
5  0 
Avatar de totozor
Membre expert https://www.developpez.com
Le 27/06/2022 à 8:28
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.
5  0 
Avatar de esperanto
Membre émérite https://www.developpez.com
Le 27/06/2022 à 15:47
Citation Envoyé par smarties Voir le message
- 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...

Citation Envoyé par lvr Voir le message
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.

Citation Envoyé par lvr Voir le message
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...

Citation Envoyé par Jeff_67 Voir le message
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.
5  1