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 !

É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

176PARTAGES

19  0 
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 ?

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

Avatar de 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.
13  0 
Avatar de blbird
Membre expérimenté 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...
12  0 
Avatar de 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.
12  0 
Avatar de JCD_31
Membre actif https://www.developpez.com
Le 12/10/2018 à 9:16
Chez 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.

11  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 12/10/2018 à 12:13
Citation Envoyé par pmithrandir Voir le message
(.../...)la hiérarchie plus accessible, etc...(.../...)
ç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...)
10  0 
Avatar de redcurve
Membre confirmé 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.
9  0 
Avatar de 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.
7  0 
Avatar de sebastiano
Membre extrêmement actif https://www.developpez.com
Le 15/10/2018 à 14:51
Quels sont selon vous les facteurs d'échec les plus importants d'un projet IT ?
- Client qui croit savoir ce qu'il veut et qui passe à côté de l'essentiel ;
- 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.
6  0 
Avatar de Grogro
Membre extrêmement actif https://www.developpez.com
Le 22/10/2018 à 11:05
Citation Envoyé par Marco46 Voir le message
Je ne vois pas du tout en quoi 2 ans d'études en plus ou en moins changerait quoi que ce soit sur la frustration. Le problème c'est qu'on est tous contraints de travailler constamment avec une majorité de débutants pour qui toutes ces notions sont une découverte (et je parle pas du management qui est par essence incompétent sur ces sujets et qui croit pertinent de venir y mettre son nez). J'ai moi-même beaucoup de mal à appliquer et faire appliquer tous les principes que j'évoque en mission tant le niveau est faible. Mais c'est normal, il ne faut pas oublier que nous sommes dans une industrie extrêmement jeune, et IMHO la frustration vient surtout de là.

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.
6  0 
Avatar de pmithrandir
Expert confirmé https://www.developpez.com
Le 19/10/2018 à 13:52
Citation Envoyé par kilroyFR Voir le message
Ok effectivement je croyais que faisais allusion a une gratification supplementaire.
Comme deja dit, ils disposent de tout (outillage, environnement), participation active au fonctionnel/technique, deplacements etc.
Le constat etant que pour la plupart seule la technique les interesse (et essaye ensuite d'y trouver une justification en deformant le besoin fonctionnel pour justifier l'utilisation des choix technos ou archi - bref ce n'est plus la technologie qui subvient aux besoins fonctionnels mais le contraire).
C'est par ce genre de comportement repeté x nb projets qu'on a decidé de reduire leur tache a du travail bete puisqu'ils n'apportaient pas de reponses a nos demandes mais essayaient de deformer notre demande pour placer leurs envies (et ca derivait sur chaque plateau, donc multiplication des sujets, egarements inutiles etc).
Tout n'etait pas mauvais pour autant mais dans la grande majorité c'etait du superflu (invendable de plus car non exprimé par client).
Voila. Notre gestion de projet est plus directive mais elle a l'avantage d'etre canalisée. Moins de surprises. On a pu baisser la pretentions des devs; eux s'y retrouvent nous aussi et on livre ce qu'on a vendu, sans chichis. Moins de devs, plus d'executants et un pole technique d'architectes (service innovation) tres reduit qui envisagent des evolutions avec l'idee de la continuité du produit (evolutivité en douceur, migration, validation des innovations et intégration dans archi en cours, support au marketing pour proposition solution innovante etc).
Bref on s'eparpille moins, on maitrise plus facilement et les sujets sensibles sont ultra localisés. Enfin ca marche depuis 6 ans comme ca et on ne s'en plaint pas; ca marche (pourvu que ca dure).
Citation Envoyé par kilroyFR Voir le message
Oui mais tout laisser dans les mains des devs jusqu'a la livraison/deploiement sur site ca n'est pas imaginable. On ne fait pas des logiciels pour nous mais pour des clients. A ce jour aucun de nos clients ne nous permettrait de faire du deploiement automatisé sur une PROD toutes les semaines. L'acces aux infras est strictement reglementé. On a des lots planifiés tous les mois avec du fonctionnel attendu.
Ceux qui font de la maintenance sont egalement sur plateau dédié toutes affaires. Generalement ils sont passés par l'etape de dev donc sont aguerris.
Ils sont sur meme infra que les autres. Nous ne pouvons acceder aux infras des clients que via VPN et lorsque le client decide de nous autoriser un deploiement sinon impensable de prendre le risque de mettre le wild dans des archis de prod (meme si en micro services, les dependances entre composants/api sont reelles, donc on ne met jamais a jour qu'une simple DLL comme on le lit dans la litterature). On a plus de 100 microservices fonctionnels.
DevOps ca va bien quand tu deploies des logiciels interne a ta boite (comme le font amazon, les grands comptes pour des applis internes etc). La partie deploiement n'est automatisée chez nous que pour nos tests (mais jamais vers les infras de PROD). Contractuellement interdiction d'acces en direct de maniere automatisé chez nos clients.

Je suis architecte (dans un petit groupe d'architectes - je suis de formation ecole d'ingenieurs EPITA a la base) dont la fonction principale est la conception/realisation de templates de logiciels (histoire que nos applis suivent toutes les memes regles, meme look, memes composants communs etc), de developpement de composants de haut niveau vus comme des boites noires pour les devs.
Donc on anticipe leurs besoins en connaissant le fonctionnel attendu, les technos en place ou celles retenues pour le projet (lorsque le client a des exigences particulieres imposées). Ils ne font principalement que de l'assemblage. C'est ce que permet l'informatique en 2018 avec une liberté qu'on n'avait pas avant.

Les problématiques complexes restent de notre domaine (ex: JAMAIS on ne va les laisser faire des deploiements en PROD directement, l'ajout de nouvelles technos ou modification de l'archi reste de notre perimetre; ce doit etre transparent pour eux).

On ne fonctionnait pas comme ca il y a 6 ans. On est toujours par plateau mais on a beaucoup moins de surprises a la fin. Celui qui sort du cadre se fait rappeler a l'ordre. Tyrannique d'une certaine façon mais pour une partie des devs qui ne sont pas des creatifs et qui ont besoin de guides ou tout simplement toujours le besoin qu'on leur tienne la main c'est ideal; ils deroulent. On a principalement besoin de bras. Le metier s'est uberisé, comme les autres. Le dev est a la portee de quiconque desormais. J'ai moi meme dans mon entourage des gens developpant (certes a leur niveau) des applications android sans qu'ils n'aient pour autant eu la formation adequate. L'autoformation pour des gens motivés et la richesse des supports disponibles permet a quiconque, motivé, curieux d'etre developpeurs aujourd'hui. Les bonnes pratiques arrivent comme dans tout metier en pratiquant et en suivant des templates.
C'est cette optique qu'on a retenue. Nos devs sont en offshore mais francophone. Ils sont aussi bons que pas mal de gens que j'ai pu rencontré dans ma carriere. Ils n'ont pas a rougir, loin de là.
Ils ne font pas de choses compliquées mais plutot des choses dont le périmetre technique/fonctionnel est ciblé. On ne cherche plus a les interesser totalement au fonctionnel. On fonctionne en micro services donc le perimetre fonctionnel est ultra bete. La complexité intrinseque a ces archis ils n'en ont aucune connaissance ni visibilité; c'est notre boulot de le gerer; eux je dirai c'est vulgairement de pisser du code. On a mis en place pas mal de templates pour generation de codes en respectant/implementant les patterns disponibles. Le code genere leur sert de base; ils s'autoforment en meme temps.

Si tu ne cadres pas un dev, naturellement il aura tendance a aller vers la facilité et le plaisir de coder. Il a son temps perso chez lui pour sa. Comme deja dit ils ont moyen de valoriser leur creativité et proposer des choses mais pas dans le cadre des heures de boulot. Il y a des primes etc. et eventuellement la possibilité d'intégrer des composants dans notre framework maison donc une forme de reconnaissance.
De toutes les methodes de dev rencontrées a ce jour, c'est la seule reellement efficace et on le constate au jour le jour. Nous n'avons a ce jour quasiment plsu de mauvaises surprises et les delais/qualités sont respectés. Archi micro services + dev off shore ca fonctionne idealement je dirai.
Voila ce n'est que l'experience dans ma boite mais je sais que pas mal de boites alentours se tournent vers ces archis car elles ont compris l'interet qu'on pouvait en retirer tres rapidement.
Si 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.
7  2