Discussion :

[Sandra Coret]

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

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

[smarties]

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

[lvr]

Ce qui manque souvent, à mon avis, c'est
1) Impliquer le client (et qu'il participe) à une véritable réflexion autour de cette modernisation. Répliquer les processus-métiers d'il y a 10 ans avec une nouvelle technologie n'a aucun sens.
Une modernisation exige aussi une mise à plat, voire une mise à jour des procédures-métier. Un travail aussi de projection sur où veulent-ils aller dans 2, 4, 10 ans. De manière à ne pas créer une application qui sera obsolète dans son démarrage.
2) (comme dit smarties) un phasage des fonctionnalités.
3) une bonne gestion des risques faites en amont, que ce soit les risques techniques, légaux, métiers, humains, ...
4) accepter de que cela prend du temps, avec des étapes qui ne semblent pas toujours utile : enterprise architecture, solution architecture, ciso, ...

En gros, cela requiert
* un client suffisamment mature, avec une réelle compréhension voir connaissance de ce qu'est une modernisation informatique,
* IT qui écoute ses équipes techniques sur le temps/difficultés/enjeux et pas uniquement ses commerciaux.
* un travail en transparence dans les 2 sens, où les mauvaises nouvelles sont dites tôt et pas les cachées en espérant les rattraper en catimi plus tard.

Et pour conclure, le problème me semble moins au niveau des outils que des processus.

[Anselme45]

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

[lvr]

Ah Anselme45, je suis toujours heureux de te voir débarquer sur une discussion où je suis actif. T'es toujours là pour faire avancer le débat dans un sens constructif et réfléchi.

[TotoParis]

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" ???

[Invité]

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

[kain_tn]

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]

Heuuuuuu, les spec...

J'ai bon ?

[totozor]

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.

[Refuznik]

Désolé, un peu vieux mais toujours d'actualité à ce que je vois.

[d_d_v]

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.

[esperanto]

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

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.

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

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.

[marsupial]

A tous vous lire, je ne m'étonne plus qu'il y ait des failles énormes dans les softs... voir log4shell

[smarties]

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.

Je me suis fait avoir une fois car la spec mise à disposition n'était plus bonne, maintenant, je fais toujours un point avec le chef de projet avant de coder une spec

Après au niveau complexité, je suis partagé entre les applications de type monolithe et les micro-services. Je pense quand même préférer un monolithe avec des modules bien séparés car ça mutualise les ressources et on peut faire de l'asynchrone aussi.

[GLDavid]

Bonjour

Une chose qui fait aussi échouer un projet: la motivation des équipes.
De mon point de vue, quand on tombe sur des partenaires qui ne sont pas motivés pour un changement ("Ca marche très bien comme ça", "j'ai pas le temps pour le changement"...), le projet est voué à l'échec d'entrée de jeu.
Le pire, quand vous êtes sous traitant, c'est que vous n'avez aucun pouvoir pour motiver les dits-partenaires. Vous rapportez à des PMOs de votre client qui vous diront: c'est à vous de les motiver, vous êtes là pour ça.

Mouais, sauf que c'est vous tous qui avez le bâton...
De la responsabilité des gens et une bonne assignation des tâches, signés par tous les stakeholders

@++

[marc.collin]

Je me suis fait avoir une fois car la spec mise à disposition n'était plus bonne, maintenant, je fais toujours un point avec le chef de projet avant de coder une spec

Après au niveau complexité, je suis partagé entre les applications de type monolithe et les micro-services. Je pense quand même préférer un monolithe avec des modules bien séparés car ça mutualise les ressources et on peut faire de l'asynchrone aussi.

je rajouterais que c'est pas tous les entreprises qui ont besoin de supporter 5000 requêtes simultanés... et qui doivent pousser des fonctionnalités en prod à tous les jours...

malgré tout, la mode est au microservice même si les besoins y sont souvent pas là

[esperanto]

Après au niveau complexité, je suis partagé entre les applications de type monolithe et les micro-services. Je pense quand même préférer un monolithe avec des modules bien séparés car ça mutualise les ressources et on peut faire de l'asynchrone aussi.

Pour ma part je suis tout à fait pour la séparation des fonctionnalités sous forme de modules (jar ou l'équivalent dans d'autres langages) placés dans des git séparés, avec des jeux de test spécifiques.
En revanche si l'architecture micro-services c'est systématiquement passer par HTTPS + REST + quinze couches de sécurité, beurk.
C'est bizarre, les programmeurs sont habitués à se connecter à un dépôt Maven (pour Java), CPAN (pour Perl), NPM (pour Javascript) et à y télécharger 200 dépendances avant même d'avoir pondu la moindre ligne de code, en revanche on dirait que personne n'est au courant qu'on peut avoir un dépôt Maven privé (pour ses propres librairies ou pour faire un miroir d'un autre dépôt). Du coup l'idée de créer des librairies qu'on mettrait sur un dépôt corporate partagé ensuite avec toute la boîte... non, faut absolument du web-service avec toute la lourdeur du réseau et ce même si au final on déploie tout sur le même serveur. Et après on nous parle de complexité...
Autrefois la mode c'était les EJB, ben au moins quand tu contactais un EJB le serveur était assez intelligent pour choisir un protocole local si l'EJB était sur le même serveur que la couche web, tout en étant capable de choisir un protocole réseau si l'EJB était ensuite déplacé. Aujourd'hui faut absolument du HTTPS partout pour tout et surtout pour n'importe quoi. Et après on te parle de complexité, elle est forcément du côté applicatif, surement pas dans les protocoles de communication...

[patrick72]

c'est souvent un problème de communication :

L'utilisateur final remonte le problème à son responsable (qui ne manipule pas lui), qui communique au commercial de la société de service, qui en discute avec le responsable des dev, qui voit avec le chef de projet attribué, qui demande à l'analyste, qui voit avec architecte, qui donne au développeur....

Au final, on obtient la classique balançoire dans l'arbre ! Il suffirait qu'une fois tout ce petit monde de responsable soit d'accord entre eux dans les grandes lignes, que l'architecte + le développeur puissent discuter avec l'utilisateur final pour obtenir un résultat simple et efficace !

[Phaeron]

A tous vous lire, je ne m'étonne plus qu'il y ait des failles énormes dans les softs... voir log4shell

Ceci n'a pas grand chose à avoir avec le sujet abordé dans les précédents messages... On est sur une faille sur une technologie opensource, maintenue certes par un acteur central(Apache), mais faisant intervenir pléthore d'acteurs ne répondant pas au modèle d'un projet "commercial" comme stipulé ci-haut.