jeudi 12 mai 2011

Jean-Pierre règle ses comptes

Au fur et à mesure de mes coups de gueules dans ce magazine, je me dévoile chaque fois un peu plus. Aujourd'hui j'avoue avoir travaillé dans plusieurs sociétés de service informatique, ce qui me permet de faire ma petite analyse critique du marché du service en France...

Le principe de concurrence c'est bien. Dans la théorie libérale cela garantit au consommateur de disposer du choix et pousse les différents fournisseurs à se démarquer par des produits de meilleur qualité. Ça c'est la théorie. En pratique, et surtout lorsqu'on l'applique à l'industrie du service informatique, c'est très souvent le moins disant qui gagne les projets mis en concurrence, pas le meilleur.
Et franchement y'en a marre des économies de bouts de chandelles qui coûtent au final des milliers d'euros de dérapage quand ce n'est pas tout simplement l'échec du projet !
Comme les appels d'offres fonctionnent selon le principe de l'enchère inversée, chaque société de service candidate va chercher à répondre aux besoins exprimés dans le cahier des charges au coût le plus faible. Ceci pour avoir une chance d'être retenu et éventuellement, si jamais c'est le cas, de s'assurer une marge financière.
Le problème est que le projet démarre déjà dans le rouge car il a été sous vendu pour pouvoir être retenu. Et cela s'aggrave en général lorsque le commercial, account manager, global partner enfin quel que soit le nom donné à Monsieur Loyal par sa société, décide d'accorder une ristourne commerciale de 15% comme preuve de bonne volonté. Une chose est sure, comme les traders, Monsieur Loyal touchera sa commission lors de la signature du contrat, avant le démarrage du projet et ne sera pas le moins du monde embêté lorsque le projet sera en pleine hémorragie financière, de ressources et de mauvaise image de l'entreprise.
Et comme le projet est déjà dans le rouge, il faut absolument démarrer avec des profils peu chers, tant pis s'ils sont tous débutants. Impossible d'investir dans un expert ou un architecte pour leur mettre le pied à l'étrier et cadrer les choix structurants. Procéder de la sorte relève, bien évidemment, de l'hérésie totale : pourquoi chercher à sécuriser le projet au calme, lorsque c'est encore possible ? Il est préférable de tenter de le faire à l'arrache, juste avant la livraison ou les tests de charge, lorsque tout le monde est en mode panique, quand c'est beaucoup plus complexe voire trop tard. C'est généralement à ce moment là qu'on se rappelle de l'existence d'experts, ceux là même qu'il aurait fallu associer au projet dès le début. Ils ne vont pouvoir intervenir qu'en mode pompier, remettant souvent en cause les choix faits il y plusieurs mois ou années. Reportez vous à mes coups de gueule précédents sur les abus d'architecture et de composants pour voir ce que le manque de recul et de bon sens peut amener les développeur à faire...

« Le bon sens est la qualité la moins partagée de ce monde » Jean-Pierre Troll
Le taux journalier moyen de l'équipe projet n'est d'ailleurs pas le seul poste d'économie. On va également réduire les coûts sur tout ce qui est considéré comme superflus... à court terme : la documentation, les tests unitaires, la définition de règles de développement, la mise en place d'outils de vérification de la qualité des développement, la gestion de la performance, les transactions, la haute disponibilité, la tolérance aux pannes, la sécurité, etc. Coûts initiaux que l'ont va devoir souvent payer au centuple sur le moyen et long terme. Qui n'a pas connu LE problème de performances rédhibitoire juste avant la mise en production ? Qui sait parfaitement que l'application mise en production est une vraie passoire au niveau sécurité ? A nouveau on va déclencher en urgence l'alarme des pompiers... ou faire l'autruche, la tête dans le sable mouvant.
Tout cela risque bien de dégoûter les développeurs juniors complètement pressurisés par un planning qui n'a jamais été réaliste et les chefs des projets dont le budget est constamment dépassé. On ne parle pas encore de suicide dans les sociétés de service. En effet, il suffit juste de démissionner. Cela prend en général trois mois, trois mois pendant lesquels on décide souvent d'ignorer le problème. Aveuglés par l'accumulation des problèmes, les managers vont oublier de véritablement gérer le transfert de compétences, le renouvellement des ressources, l'audit par les pères, etc. Ce qui amène généralement à une situation encore pire que précédemment. Combien ai-je connu de situations catastrophiques où plus personne ne connaissait l'historique du projet, la justification des choix techniques car cela faisait déjà les troisièmes ou quatrièmes chef de projet et architecte qui « reprenaient » les choses en main ? Reprise en main jusqu'à la prochaine démission ou décapitation par le haut du management, agacé d'avoir à se justifier devant le PDG du client mécontent du retard et de la qualité des livraisons...
Et le client, parlons en du client. Il impose souvent des choix techniques absurde, mais demande à la société de service de s'engager alors sur les performances ! Impossible. Il exprime ses demandes en termes de « solution technique » et non en termes de « besoin ». Comme personne n'ose lui dire non, le projet se précipite sur les solutions préconisées, même s'il est évident qu'elles ne peuvent répondre au besoin. Combien de projets plombés par une règle considérée comme « imposée par le client », qui en fait, n'était qu'une « suggestion » de ce dernier ? Bien plus tard, on indique on client que tel problème est le fait de tel choix qui a été imposé. Le client répond alors, très justement, que cela n'a jamais été le cas !
La bonne approche selon moi ? Comme pour les traders, payer les primes des commerciaux à la fin du projet, et non au début, suivant les résultats réels. Faire intervenir des experts au début du projet, pour structurer le code, rédiger l'infrastructure et les couches techniques, et les éloigner du projet dès que possible. Ensuite, et seulement ensuite, faire intervenir des débutants et autres ressources moins couteuses.
Les anglo-saxons ont un dicton que je trouve formidablement imagé et évocateur. Ainsi, plutôt que de dire que l'on va droit dans le mur, ils suggèrent : « When the shit hits the fan... » (Quand la m... atteint le ventilateur). Et c'est bien vers cet événement que dérive naturellement le projet, le clash, le vrai, celui qui va éclabousser tout le monde. Que faire dans une telle situation ? Se protéger en passant beaucoup de temps à « blinder » le projet pour ne pouvoir être attaqué en justice. On ouvre le dossier contentieux avec le client, dès les premières lignes de code. Ou bien il faut sauter du navire lorsqu'il est encore temps... On voit qu'au final, on est bien loin de la promesse théorique de la meilleure offre.
Donc que cela soit clair une bonne fois pour toute :l'offre la moins chère n'est probablement pas la meilleure, et se transforme probablement pas non plus dans le projet informatique le moins cher. Au contraire. Il faut suivre cette stratégie :

« Éliminez l'offre la moins chère de tout appel d'offre, elle sens mauvais » - Jean-Pierre Troll.
Quelle (r)évolution cela ferait ! Une simple règle comme celle-ci obligerait les soumissionnaires à plus de pragmatisme et de réalisme.
Un collègue m'évoquait qu'en Allemagne, il y a peu de dérive sur les projets informatiques. Pourquoi ? Car s'il est estimé qu'il faut 1 an pour le faire, on ne le vend pas pour six mois. C'est simple. Les clients le savent, et son prêts à payer pour un résultat. En France, les clients préfèrent payer pour un échec. Allez comprendre.
Alors que faire devant un tel constat ?
Peut-être faudrait-il s'inspirer de l'industrie du BTP ? Elle est certes souvent décriée comme une industrie pourrie, où existent de nombreuses pratiques douteuses... Certes. Et si les différentes sociétés de services se mettaient d'accord pour fixer des prix minimaux sur les appels d'offres voire signeraient une charte de déontologie financière (mais là c'est du rêve éveillé) ?
Une autre approche, consiste à une entente illicite, de partage du marché. Untel répond à tel client. En échange, untel peut répondre convenablement pour tel autre client. Des générateurs de réponse à appel d'offre ont été découverts dans certaines entreprises pour pouvoir générer des offres « trop disantes » et ainsi simuler la concurrence.
Avec un tel partage du marché, plutôt qu'une guerre des prix (complètement inefficace dans une activité de service), peut être que l'industrie du service en France serait mieux portante ? L'atmosphère dans les projets des sociétés de services serait plus saine et plus vivable, peut être même (soyons fous !) que plus de projets arriveraient à leur terme et surtout, conformes aux besoins des clients.

Aucun commentaire:

Enregistrer un commentaire