Étude : 50 % des projets de développement d'applications se soldent par un échec
Cela est-il dû à la lenteur des codeurs et la dette technique ?

Le , par Michael Guilloux, Chroniqueur Actualités
Si une entreprise peut se permettre de démarrer de nouveaux projets informatiques chaque année, garantir leur succès est une chose qui est bien moins évidente. Pour réussir, un projet doit en effet respecter des contraintes de coût, de délai et de qualité (respect des exigences définies par le cahier de charges). Mais dans la pratique, il est difficile de voir un projet respecter ces 3 critères, et les meilleurs projets sont ceux qui arrivent à terme avec un écart relativement faible par rapport à ces critères.

Plusieurs études ont été menées sur la réussite des projets informatiques, et la plupart s'accordent sur le fait qu'une bonne partie (parfois la majorité) des projets informatiques se soldent par un échec. Précisons que la notion d'échec ici signifie que soit le projet n'est jamais lancé ; soit il est lancé, mais n'est jamais terminé ; soit il est terminé, mais ne répond pas aux besoins exprimés par les utilisateurs. C'est cette définition d'échec qui a été utilisée dans une étude menée par IDG (International Data Group) pour la plateforme de développement low-code Appian.

Pour cette étude, plus de 500 décideurs et responsables IT issus d'entreprises de plus de 1000 employés ont été interrogés. Précisons que plus de la moitié des répondants étaient des employés dits de niveau C (CIO, CTO, CSO). L'étude montre que les grandes entreprises aux États-Unis et en Europe (Allemagne, Espagne, France, Royaume-Uni) adressent chaque année à l'IT en moyenne 180 demandes de nouveaux projets (développement d'applications, améliorations ou autres). Ce qui, selon IDG, indique que ce type de demande monte en flèche au niveau mondial. Par région, les entreprises européennes font beaucoup plus de demandes que leurs homologues US. Le nombre de demandes de nouvelles applications ou améliorations chaque année s'élève à 150 en moyenne pour une entreprise US, contre 230 pour une entreprise de la zone EMEA (Europe uniquement).


Toutefois, le résultat le plus frappant de l'étude est que 50 % de toutes les nouvelles demandes de développement d'applications se soldent par un échec. Dans les détails, l'étude révèle que 15 % de ces projets ne sont jamais lancés, 15 % ne sont jamais terminés et 20 % sont livrés, mais ne répondent pas aux besoins de l'entreprise.


Aux États-Unis, le département Marketing est plus susceptible que les autres départements de demander de nouvelles applications, tandis que dans la zone EMEA, c'est le département Ventes qui est le plus gros demandeur d'applications.

Quelles sont les causes d'un tel taux d'échec ? Dans ce qui ressemble à une tentative de désigner des responsables, le rapport indique que « les services informatiques ont du mal, ou n'arrivent pas, à répondre aux besoins évolutifs de l'entreprise, principalement en raison de la lenteur du codage et des problèmes liés à la dette technique. » La dette technique, définie comme le coût implicite du travail supplémentaire lié au choix d’une solution facile immédiate au lieu de la solution appropriée de long terme, « représente une partie majeure du problème », peut-on lire dans le même rapport.

D'après l'étude, si les équipes IT passent 50 % de leur temps à coder de nouvelles applications et améliorations, elles prennent environ 40 % du temps consacré au développement pour gérer la dette technique. La dette technique a donc un impact considérable sur les entreprises. En effet, pour 55 % d'entre elles, la dette technique augmente les coûts opérationnels. 52 % des répondants estiment aussi que la dette technique fait que le développement d'une fonctionnalité simple prend plus de temps que prévu. Jusqu'à 47 % estiment encore que la dette technique réduit les performances et l'évolutivité des applications, alors que pour 37 % des personnes interrogées, cela rend plus long le temps nécessaire pour mettre une application sur le marché. Enfin, 17 % des répondants estiment que la dette technique empêche les améliorations de l'expérience client. Seuls 5 % des entreprises disent ne pas avoir expérimenté de dette technique.


Pour ce qui est des sources de la dette technique, aux États-Unis, ce sont les décisions IT (47 %) et la pression de livrer les applications (43 %) qui sont le plus souvent pointées du doigt. En Europe, c'est plutôt la mauvaise documentation des exigences des projets (42 %).


Sources : Appian, Infographie de l'étude, Détails de l'étude

Et vous ?

Que pensez-vous des résultats de l'étude ?
Quels sont selon vous les facteurs d'échec les plus importants d'un projet IT ?
En tant que développeur, gérer la dette technique fait-il partie de votre quotidien ? Combien de temps y accordez-vous en moyenne dans la semaine ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse Signaler un problème

Avatar de Ryu2000 Ryu2000 - Membre extrêmement actif https://www.developpez.com
le 10/10/2018 à 15:02
Citation Envoyé par Michael Guilloux Voir le message
Pour réussir, un projet doit en effet respecter des contraintes de coût, de délai et de qualité (respect des exigences définies par le cahier de charges).
Je suis contre le concept de "cahier des charges" pour les projets informatique.
Il faut trouver d'autres solutions.
Le client n'exprime pas correctement son besoin, les développeurs comprennent mal le besoin du client, le besoin du client évolue, etc.
Il faut faire du développement agile, il faut avoir des réunions régulière avec le client pour qu'il puisse guider la direction à prendre.

Citation Envoyé par Michael Guilloux Voir le message
Dans les détails, l'étude révèle que 15 % de ces projets ne sont jamais lancés, 15 % ne sont jamais terminés et 20 % sont livrés, mais ne répondent pas aux besoins de l'entreprise.
Ça il faudra s'en rappeler : 20% des projets livrés ne répondent pas aux besoins de l'entreprise.
Ça veut dire que c'est hyper commun qu'une entreprise paie des développeurs pendant longtemps pour rien du tout.

Il y a des développeurs qui ont travaillé pendant des années, pour rien.
Avatar de blbird blbird - Membre éprouvé https://www.developpez.com
le 10/10/2018 à 15:46
Personnellement, au niveau des grandes entreprises, ce qui est le plus impactant pour les nouvelles ou les modifications d'applications existantes, ce sont les délais demandés par les métiers.

Très souvent ces délais sont ridiculement faibles comparé aux temps de développement. Dernièrement, dans une grande entreprise, le métier m'a expliqué que 90 jours de charges de développement d'un nouveau projet informatique c'était beaucoup trop, ils le voulait fini en moins d'un 1 mois. Leur solution (véridique) : mettre 9 développeurs et c'est fini en 10 jours...
Avatar de Ryu2000 Ryu2000 - Membre extrêmement actif https://www.developpez.com
le 10/10/2018 à 15:49
Citation Envoyé par blbird Voir le message
mettre 9 développeurs et c'est fini en 10 jours...
C'est comme la blague du chef de projet qui pense qu'en mettant 9 femmes il peut avoir un bébé en 1 mois.
Avatar de redcurve redcurve - Membre averti https://www.developpez.com
le 10/10/2018 à 17:13
Avec des délais qui ne correspondent à rien, une organisation des entreprise datant du 19ème siècle, des décideurs qui ne savent rien etc. oui le taux d'échec est nécessairement faramineux.
Avatar de mister3957 mister3957 - Membre expérimenté https://www.developpez.com
le 10/10/2018 à 17:13
Pour moi la principale cause est la course au moins cher / au plus rapide, sinon c'est le concurrent qui choppe le projet.

Alors pour rentrer dans les exigences clientes, dans les bons chiffres qui vont bien lors d'une réponse à appel à projet, les commerciaux sortent des trucs de leurs chapeaux, enquillent leurs primes et ensuite les pilotes / techs se débrouillent avec ce qu'ils ont.

Du coup on met moins de bonhommes, et on en met des pas chers, on limite fortement la préparation au projet et donc son pilotage dans l'ensemble et puis il n'y a plus qu'à presser les devs comme des citrons avec objectif "le bouton il faut qu'il marche". Et si ça foire, c'est à cause d'eux.

Par ailleurs il y a encore beaucoup trop cette mentalité "le client est roi" qui fait qu'on lui laisse trop de pouvoir dans le pilotage (alors que l'on est sensé lui vendre ça aussi, ainsi que l'accompagnement et de la conduite du changement).

Parfois lorsque ça ne correspond pas au besoin, ça peut venir également du client, ils ont des gugusses aussi de leur côté qui sont bien éloignés des utilisateurs finaux. Donc la maîtrise d'ouvrage comme la maîtrise d'oeuvre sont bâclées, d'ailleurs les frontières ne sont pas claires dès le départ.

Pour des projets internes, c'est pareil, sauf que le client ce sont ces fameux "mecs du conseil".

L'agilité c'est bien mais peu comprennent ses rouages et très très peu y sont formés, c'est souvent pour faire effet de mode c'est tout mais dans le fond les roadmaps sur des années sont bien là, et à respecter car déjà vendues. Ça arrange bien les "chefs", on a posé le déterminisme du cycle en V sans se casser la tête à écrire ces specs barbantes.

Mais du coup c'est pire, les devs doivent avancer à l'aveugle, bouton après bouton, et au moindre sujet de fond qui tombe, ça fait parfois mal, souvent trop mal, et flop ! En général les gens se barrent, et puis on reprend les mêmes "chefs", les mêmes commerciaux, et on revend des trucs, on trouve d'autres petits jeunes et on recommence.

J'ai déjà entendu dire "ce qui nous fait gagner de l'argent, c'est pas le projet mais sa TMA". Et j'ai taffé dans une boite où la stratégie était de berner le clients jusqu'à ce qu'il atteigne un point de non retour financier, donc obligé de continuer avec eux, ça fait de la tréso régulière, de la visibilité financière, un monde parfait, c'est génial... jusqu'à ce que le juridique du client s'en mêle, un autre avantage de l'agilité, on ne s'engage pas, c'est parfait.
Avatar de Grogro Grogro - Membre extrêmement actif https://www.developpez.com
le 10/10/2018 à 17:48
Citation Envoyé par redcurve Voir le message
Avec des délais qui ne correspondent à rien, une organisation des entreprise datant du 19ème siècle, des décideurs qui ne savent rien etc. oui le taux d'échec est nécessairement faramineux.
Et des subordonnés (cadres intermédiaires, chefs de service, product owners) qui n'osent remonter aucune alerte aux décideurs, aucune information discordante, de peur que la tête qui dépasse se prenne le coup de marteau.
Avatar de mister3957 mister3957 - Membre expérimenté https://www.developpez.com
le 10/10/2018 à 20:26
Citation Envoyé par Grogro Voir le message
Et des subordonnés (cadres intermédiaires, chefs de service, product owners) qui n'osent remonter aucune alerte aux décideurs, aucune information discordante, de peur que la tête qui dépasse se prenne le coup de marteau.
L'ingérence.. ça ressemble à un art de vivre dans notre métier.

99% de ce que l'on fait se trouve sous un capot avec 10.000 verrous, donc l'ingérence est ultra propice.

Il n'y a qu'à voir dans l'univers automobile, on peut ouvrir le machin, le décortiquer, l'analyser, ça donne lieu à des études, des magazines papier / émissions de TV, tout est transparent.. sauf lorsque ça touche au numérique, boites noires, donc on en profite pour y mettre des saloperies dedans, on s'en fou y'a personne qui voit.
Avatar de sergio_is_back sergio_is_back - Membre expérimenté https://www.developpez.com
le 11/10/2018 à 8:29
Citation Envoyé par Ryu2000 Voir le message
Je suis contre le concept de "cahier des charges" pour les projets informatique.
Il faut trouver d'autres solutions.
Ça a au moins le mérite de poser les bases. Mais comme beaucoup je reçois des CDC qui tiennent sur deux pages rédigés à la vite

Citation Envoyé par Ryu2000 Voir le message

Le client n'exprime pas correctement son besoin, les développeurs comprennent mal le besoin du client, le besoin du client évolue, etc.
Oui tout ça c'est vrai... Il faut souvent passer beaucoup temps que ce soit au téléphone, sur site avec le client pour bien préciser les limites et tous les aspects...
Cet aspect là n'est pas pris en compte dans un chiffrage souvent et c'est pourtant primordial, plus un CDC est flou et plus il faut chiffrer et vendre de l'analyse et de la gestion de projet
Alors comme souvent ça n'a été chiffré et vendu on évite de perdre du temps avec ça et le projet part en sucette...

Citation Envoyé par Ryu2000 Voir le message

Il faut faire du développement agile, il faut avoir des réunions régulière avec le client pour qu'il puisse guider la direction à prendre.
Attention avec le développement Agile j'ai vu certaines boîtes faire tester le soft directement par le client et livrer 10 ou 12 versions dans la semaine avec des bugs d'affichage et même des plantages pur et simples en production dans ces cas c'est du détournement de ressources pur et simple et des pertes d'exploitation pour le client et ça nui à la relation avec celui-ci
Avatar de Ryu2000 Ryu2000 - Membre extrêmement actif https://www.developpez.com
le 11/10/2018 à 8:43
Citation Envoyé par sergio_is_back Voir le message
Ça a au moins le mérite de poser les bases. Mais comme beaucoup je reçois des CDC qui tiennent sur deux pages rédigés à la vite
D'un côté c'est parfois mieux.
Il faut juste bien comprendre les fonctions principales et commencer par concevoir ça.
Avoir un cahier des charges qui contient trop de petits détails qui ne servent à rien, ça fait perdre du temps... C'est un coup à développer plein de fonctions qui ne servent à rien.

C'est quasi impossible de savoir à l'avance ce qui serait le mieux pour le client dans des années.

Exemple de bon cahier des charges (Citroën 2 chevaux) :
« Faites étudier par vos services une voiture pouvant transporter deux cultivateurs en sabots, cinquante kilos de pommes de terre ou un tonnelet à une vitesse maximum de 60 km/h pour une consommation de tois litres d’essence aux cent. En outre, ce véhicule doit pouvoir passer dans les plus mauvais chemins, il doit être suffisamment léger pour être manié sans problèmes par une conductrice débutante. Son confort doit être irréprochable car les paniers d’oeufs transportés à l’arrière doivent arriver intacts. Son prix devra être bien inférieur à celui de notre Traction Avant »
Citation Envoyé par sergio_is_back Voir le message
Oui tout ça c'est vrai... Il faut souvent passer beaucoup temps que ce soit au téléphone, sur site avec le client pour bien préciser les limites et tous les aspects...
Il faut être en contact avec ceux qui utilisent réellement l'outil.
Avoir une réunion 2 fois par mois pourrait être utile.

Citation Envoyé par sergio_is_back Voir le message
j'ai vu certaines boîtes faire tester le soft directement par le client et livrer 10 ou 12 versions dans la semaine
D'un côté ça fait gagner du temps sur le test, vu que c'est le client qu'il les fait ^^
Par contre si c'est en production ça craint...
Avatar de Doksuri Doksuri - Membre émérite https://www.developpez.com
le 11/10/2018 à 9:00
Quels sont selon vous les facteurs d'échec les plus importants d'un projet IT ?
les delais trop cours et le manque de reflextion avant le lancement du projet (surtout par les non-dev).
on ne vous consulte pas et un jour : "bon, on va faire le projet X, on a 3 mois" .... au bout d'un moment, on se trouve confronte a un probleme : "mais vous avez pense a X ? et Y ? et pourquoi vous n'avez pas pense a Z ?"
du coup, comme les devs sont deja engages, on trouve des solutions a l'arrache. ce qui amene a la reponse suivante ....
En tant que développeur, gérer la dette technique fait-il partie de votre quotidien ? Combien de temps y accordez-vous en moyenne dans la semaine ?
gerer la dette tecnique est le quotidien... si on prend du debut du codage a la resolution du dernier bug remonte par le client : 50% du temps
exemple : si le dev dure 3mois, on va debugger pendant 3mois (pas a 100% de debug, on va faire d'autres projets en meme temps) mais pendant 3mois, on aura une petite liste de bugs a traiter
Contacter le responsable de la rubrique Accueil