É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 2018-10-10 14:50:01, 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 ?
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 ?
-
blbirdMembre chevronné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...le 10/10/2018 à 15:46 -
Ryu2000Membre extrêmement actifC'est comme la blague du chef de projet qui pense qu'en mettant 9 femmes il peut avoir un bébé en 1 mois.le 10/10/2018 à 15:49
-
mister3957Membre expérimenté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.le 10/10/2018 à 17:13 -
JCD_31Membre avertiChez nous, nous avons tout ce qu'il faut pour réussir un projet :
- Un directeur qui ne parle que de délocaliser la production parce que c'est trop cher
- Un "manager" qui donne l'impression d’être un technicien que l'on a catapulté manager et qui n'a aucune espèce d'idée de ce qu'il fout là (et qui passe plus de temps à faire de la veille techno que des trucs de manager)
- Un "architecte" arrogant et incompétent qui ne manquera pas de te rabaisser à la moindre occasion ("mais tu sais pas ça ? mais t'es un gros nul ! "
- Un commercial. Tout est dans ce mot.
- Un chef de projet interne. Bon, ok, rien à dire sur celui là, il tient la route et il est compétent.
- Une "responsable projet" hystérique et intrusive qui n'a que les mots "marge", "estimation", "reste à faire" et "points de fonction" à la bouche.
- Des développeurs juniors découvrant ce monde merveilleux, jetés comme des Hobbits en Mordor.
- Des développeurs séniors qui se cassent parce qu'ils en ont assez ce cette merde
- Et moi, entre deux eaux, assez blasé de la vie pour m'en frangipaner de tout ça, et qui ne regarde que la somme inscrite en bas de son bulletin de paie en fin de mois et qui se dit qu'il devrait changer de métier.le 12/10/2018 à 9:16 -
el_slapperExpert éminent séniorça, c'est un sujet énorme en soi. Je suis au CHSCT, alors j'entends parfois des histoires assez édifiantes. Entendu juste hier, un exemple; deux programmeurs se sont fait refourguer un projet merdique, non documenté, avec forte pression pour livrer. A la mi Juillet, la chef va les voir :
_Bon, ben on en a besoin pour fin Juillet. Donc vous aurez fini.
_Hein? Quoi? mais même fin Septembre, c'est impossible, vu tout ce qu'il reste à faire, et toute la dette technique à travers laquelle nous nageons!!!(notons que la chef comprend le terme de dette technique).
_Je m'en fous que ça soit impossible. Pensez que c'est possible, et vous allez y arriver. Allez, juste un dernier effort!!!
Résultat, fin septembre, le projet a été classé "non prioritaire". Toujours pas fini. Parmi les deux programmeurs, la dame multiplie désormais les arrêts maladie, et le monsieur a frôle le burnout. Je le soupçonne de préparer son départ pour ne pas finir comme la dame. Cela surprendra-t-il quelqu'un?
(et on est une bonne boite; j'ai vu tellement pire ailleurs...)le 12/10/2018 à 12:13 -
redcurveMembre extrêmement actifAvec 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.le 10/10/2018 à 17:13
-
GrogroMembre extrêmement actifEt 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.le 10/10/2018 à 17:48
-
GrogroMembre extrêmement actif
En un sens si, puisqu'on fait un bac+5 pour faire un travail d'ingénieur (qu'on ait le titre ou non, une énième aberration franco-française sur laquelle on ne va pas revenir), avec une paye d'ingénieur, pas pour faire un boulot de technicien, simple exécutant à qui il est interdit la moindre initiative, même si cela lui sera reproché en entretien annuel ensuite pour prétexter le gel du salaire pendant N années, avec une paye inférieure à un technicien. Les métiers de l'informatique ont quelque chose de pathologique en France.
La frustration des débutants vient aussi que 90% des projets sont de la maintenance, parfois chez le client, parfois en CDS. Sans doc, sans normes de codage, allant à l'encontre de toutes les bonnes pratiques qu'on leur a apprises à l'école, avec une architecture spaghetti, sans ORM (ou plusieurs bouts d'ORM maison qui se télescopent), et un code dégueulasse qui relève d'une sédimentation de micro-décisions aberrantes sur des années. Parce que des dizaines de presta s'y sont succédé au fil des ans. Et sur des technos ancestrales genre java 6 avec des bibliothèques maison qui sont des copier-coller de bouts de bibliothèques standard, mais qu'il est interdit d'utiliser pour des raisons X ou Y (qui ont pu avoir une légitimité à une époque mais qui semblent arbitraires). Avec genre du Struts pour le front. Ou devbooster (ceux qui ont bossé pour le crédit mutuel comprendront). Mais ce code marche, et le refondre ça prend énormément du temps, et c'est un gros risque.
Pour en rajouter à la frustration, pas mal de jeunes diplômés ont pu faire leur alternance dans une vraie entreprise avec de vrais projets. Quand on se retrouve ensuite à faire de la merde indigente en SSII parce que c'est 90% du marché de l'emploi, pour une paye indigente, ça file une énorme claque. Et j'en ai vu pas mal devenir cyniques ou désabusés en quelques mois. Ou devenir simplement mauvais, sans aucune rigueur, alors qu'ils semblaient prometteurs avec de bonnes capacités. Ce qui génère aussi beaucoup de frustrations côté client puisque ces ressources leur ont été vendues comme "experts" par le commercial du viandard. Or ces SSII embauchent à 80% des débutants (jeunes diplômés ou moins de 2 ans d'expérience). Et si le commercial est honnête, c'est la SSII concurrente qui décroche le contrat. Un gros contrat perdu ça fait parfois TRES mal (cf les mésaventures de Sopra Steria Banking la semaine dernière).
Quand on fait de la presta en SSII, on bosse souvent sur des grands comptes. Ce sont des projets intéressants quand on sort de la technique pour appréhender le métier, mais qui sont abrutissants au possible pour un développeur, qu'il soit bon ou mauvais (et s'il est bon, en quelques mois il deviendra au mieux moyen tellement il sera sous utilisé). Et les débutants découvrent toutes les rigidités de l'entreprise française ultra verticalisée, son management franco-français catastrophique, la culture du présentéisme, ses silos métiers étanches, où la moindre demande d'information qui doit passer par le N+2, puis par le chef de service rival du N+2, dont les dents rayent le parquet pour se faire bien voir du N+3 et du N+4. Découvrent empiriquement le principe de Peter voire de Dilbert, les délires de la cellule marketing sous coke (). Les spécifications fantaisistes, lacunaires, ou contradictoires, qu'on leur demande d'appliquer au pied de la lettre le plus rapidement possible.
Il y a aussi un gros malentendu dès l'école puisque le développement n'est qu'une composante de notre métier. Notre métier, c'est la prestation de services pour le tertiaire. Nous sommes en quelque sorte tous des consultants low cost, et le développement n'est qu'un outil à mettre au service du métier et de l'utilisateur final. Beaucoup de dev ne le comprennent jamais. De mon point de vue, c'est pourtant l'articulation entre le métier et la solution logicielle qui constitue la partie la plus intéressante du métier. C'est pour ça que sont faites les architectures micro-services.
On est je crois le seul pays au monde où le SI n'est pas considérée comme un métier de l'entreprise mais comme un coût et une charge à externaliser le plus possible. On a une culture d'entreprise maladive jusqu'à l'os en France.le 22/10/2018 à 11:05 -
sebastianoMembre extrêmement actifQuels sont selon vous les facteurs d'échec les plus importants d'un projet IT ?
- Manquement au devoir de conseil du prestataire (et ça induit toute la chaîne, du DP au Dev en passant par le CP, le commercial etc.) ;
- Développeurs qui comprennent mal le besoin par manque de visibilité globale du projet ;
- Service commercial qui fait passer des choses en douce et/ou sans savoir l'impact sur le projet en cours ;
- Client qui change d'avis en plein projet (et je ne parle pas de modifier une fonctionnalité mais d'un impact sur tout un pan du logiciel) ;
- Méconnaissance du métier du client par le prestataire ;
- Méconnaissance du métier informatique par le client.le 15/10/2018 à 14:51 -
pmithrandirExpert éminentSi vous etes intéressé par un feedback, lisez la suite.
Tous vos post reflete un état d'esprit. Je ne sais pourquoi, mais vous donnez l'impression d'etre supérieur aux autres, d'assimiler tous les dev aux même travers.
Ce n'est pas une équipe qui est dénaturée, mais toutes les équipes... De mon coté, j'ai tendance a essayer de trouver lr point commun a ces situations, et ce n'est pas obligatoirement qu'ils sont tous dev...
De mon experience, j'ai toujours rencontré des dev qui voulaient en savoir plus. Même ceux qui pretendaient le contraire creusait le besoin fonctionnel quand on leur en donnait l'occasion.
Oui, ils aiment parfois développer des choses nouvelles, mais souvent c'est parce que :
- leurs suggestions honnetes ne sont jamais acceptées(ce n'est pas une priorité métier)
- on les prend pour de la merde, donc ils construisent leur CV.
En général, ca va de pair avec un turn over important.
Je ne vous connais pas, vous n'aurez peut être rien a faire de mon feedback, mais je vous conseille de faire une introspection forte de votre manière de travailler, de l'image que vous vehiculez, etc... Demandez juste des feedback par exemple tous les 6 mois 2 ou 3 fois de suite. Et réagissez par un plan d'action aux difficultés remontées. Vous serez je pense étonné de la justesse de certains retour, et surement de leur coté généralisé.
Bon courage si vous prenez ce chemin, il va être dur à suivre et difficile à encaisser... mais dans 18 mois je peux vous promettre que vous serez à un tout autre niveau professionnel.le 19/10/2018 à 13:52