La confiance et le contrat

1ère partie : This is Broken…

Chers consultants, assistants maîtres d’ouvrage, informaticiens, architectes, développeurs (…), avez vous déjà pensé lors d’un kick off projet, proprement signé et engagé : “Arg, qu’est ce que je fais la, je le sens mal ce truc, c’est mal parti ce projet…” ? Oui?

Oui, je n’en doute pas… Les raisons objectives sont multiples, budget trop faible, périmètre mal cerné, objectif flou, manque de sponsoring, manque de maîtrise technique ou métier etc…

L’objet de cet article n’est pas de refaire cette liste, je n’ai aucun doute que vous la maîtrisiez, mais plutôt réfléchir ensemble au processus d’émergence comme cause significative des échecs et dérapages de projet.

Bien sur, et fort heureusement, d’autres projets se passent bien!

Laissez-moi vous poser la même question mais dans un autre contexte : des vacances au ski. Bizarrement, cette situation n’a jamais été vécue en ce qui me concerne; pourtant c’est aussi un projet! Mais il est engagé un peu différemment…

L’envie et la confiance sont les fondements d’une équipe projet

Pour des vacances, l’objet est maîtrisé, mais surtout nous en avons envie et nous sommes dans un climat de confiance; Et bien oui, l’envie et la confiance sont les fondements d’une équipe projet et de son engagement.

Mais quand on y pense, la signature d’un contrat de réalisation informatique se fait au moment ou la confiance entre les deux parties est la plus faible, puisqu’on ne se connait pas encore! C’est encore plus paradoxal aujourd’hui car de nombreux outils permettant de mieux se connaitre font partie de notre quotidien (>> indice-teasing sur la second partie !).

L’engagement se signe au moment ou la confiance est la plus faible

Bon, on a un budget, un objectif, il faut bien l’engager ce projet! Alors comment ça se passe ? Depuis une bonne trentaine d’année, le commanditaire écrit un cahier des charges, l’acheteur (qui peut être la même personne dans des structures plus petites) organise l’appel d’offre (ou plus simplement la mise en concurrence), les entreprises susceptibles de transformer ce besoin en réalité répondent avec une proposition technique et commerciale, l’acheteur dépouille et sélectionne la meilleure proposition, souvent par le biais d’une soutenance orale ou d’un second rendez-vous. La signature du contrat qui fait suite à ce processus, est alors l’unique vecteur de confiance entre le client et son fournisseur. C’est long (entre 1 et 12 mois) et surtout c’est mécanique…

L’informatique et le conseil sont des histoires de relation humaine (H2H), les jours de développement ne se comptent pas en palettes ou en conteneurs, et la qualité est aussi complexe à objectiver que les compétences. Des certifications existent certes — ce sera l’objet d’un article complémentaire — j’en maîtrise quelques unes mais je n’y crois que moyennement…

La confiance est concentrée sur quelques hommes clefs

Des hommes clefs, foncièrement relationnels et expérimentés, sont les générateurs de ce business. Il portent des noms différents — ingénieurs d’affaire, managers, commerciaux, business developer, responsables grands comptes, associés, apporteur d’affaire— en fonction des entreprises et organisations.

Leur plus-value c’est leur réseau et leur capacité à générer et maintenir la confiance auprès des clients. Cela leur octroie un ascendant hiérarchique sur ceux qui réalisent.

le client achète un CV et non plus un projet

Au final, le client achète le(s) CV(s) et non plus le projet. C’est bien plus sécurisant, en phase d’émergence. Qui ne ferait pas pareil? ça évite même d’avoir à définir précisément l’objectif du projet! Le prestataire est remplacé si il ne convient pas, car l’engagement contractuel est prévu pour ça. C’est le modèle d’achat de prestation en régie.

Et l’informatique se transforme lentement mais surement en de l’intérim de luxe, on va se placer au chaud chez un client sur des “projets à 2 ans” … Tout va bien. Pour la société informatique le chiffre d’affaire est récurrent, pour le prestataire le salaire tombe en fin de mois, et pour le client la main d’oeuvre est disponible et “corvéable à merci”, un transfert de responsabilité sociale.

La notion de projet et d’engagement disparaît…

et il y a 3 “Hics” :

• Le premier “Hic” est associé à la négociation. On achète des jours, beaucoup de jours, et comme dans la grande distribution, on négocie sur le volume… Va négocier ton salaire et ton évolution quand tu es placé pendant 2 ans chez un client et facturé au rabais…
• Second “Hic”, l’adaptabilité, autrefois une grande force du consultant-expert, prend un bon coup dans l’aile… On monte une équipe projet avec ceux qui sont disponibles en priorité et on les place à tout prix chez un client. Le prestataire s’adaptera, il aura le temps de monter en compétence chez le client, ou on proposera un remplacement. La priorité est de payer le staff après tout.
• Le troisième “Hic” va pour le client, responsable du projet, qui doit passer plus de temps à manager une équipe qui n’est pas la sienne par le biais de contrats, renouvellement, remplacements, qu’il n’en passe sur son projet. Frustrant.

Ça donne par exemple des architectes IT (5 ans d’étude et 15 ans d’expérience) facturés une paille qui font des plannings; des développeurs payés au lance-pierre, qui font de la maintenance réseau ou des slides Powerpoint, et des projet qui dérapent voire disparaissent… bienvenu dans le souk de l’informatique. En prime, c’est le petit bonus “stress for all”, cadeau de la maison^^…

Ainsi, les bons codeurs, mal considérés et lassés par une méthode d’engagement qui valorise la vente et la relation client plus que le produit, le savoir-faire et le service rendu, sont de plus en plus rares. Business first…

Mince j’ai commencé cet article en disant que les projets étaient des histoires de relations humaines… Pas d’inquiétudes! la seconde partie de la réflexion porte un peu plus d’optimisme…