+32 473 52 49 31Lun–ven · 08:30–18:00
Vous préférez d'abord en parler ? Appelez-nous.
Make IT So

Blog · Gestion de programme

Pourquoi les partenaires IT externes échouent souvent (et comment l'éviter)

Trois fournisseurs qui échouent d'affilée, c'est rarement la faute de mauvais fournisseurs. Tout commence par la sélection et les accords. Voici ce qui fonctionne.

Pourquoi les partenaires IT externes échouent souvent (et comment l'éviter)

Une PME de Malines venait de devoir se séparer de son troisième fournisseur IT d'affilée. Son CEO m'a demandé, frustré :

« Walter, comment se fait-il que nous retombions toujours sur le même problème ? Ils promettent des montagnes d'or et livrent des tas de cailloux. »

Nous entendons cette histoire trop souvent. Et même s'il est tentant de rejeter la faute sur les fournisseurs, le vrai problème se situe généralement plus tôt dans le parcours : dans la sélection et dans les accords conclus. Les deux parties portent une part de responsabilité dans ce qui tourne mal ensuite.

Le schéma que nous voyons revenir sans cesse

Trois fournisseurs d'affilée qui suivent le même schéma : un début enthousiaste, des fissures à mi-parcours, une fin en crise. Les entreprises accusent les fournisseurs, mais le schéma dit autre chose. Quand trois acteurs différents obtiennent le même résultat, le problème réside dans la façon dont la partie se joue, pas seulement dans qui la joue.

Quatre raisons pour lesquelles les partenariats IT échouent souvent

Des attentes floues dès le premier jour

« Nous voulons un système qui sait tout faire. » Cette phrase revient régulièrement dans les réunions de cadrage. Le problème ? « Tout » ne veut pas dire la même chose pour chacun. Le fournisseur pense à une solution standard avec un peu de paramétrage, le client rêve d'une Ferrari sur mesure. Chacun part avec une image différente, et cet écart ne fait surface que des semaines plus tard, lors d'une réunion où, soudain, plus personne ne comprend ce que l'autre veut dire.

Une communication qui ne passe pas

Les gens de l'IT ne parlent pas la même langue que les gens du métier. Là où le fournisseur parle d'« intégrations APIUne convention fixe qui permet à un logiciel de communiquer avec d'autres logiciels. Un programme envoie une requête via internet, l'autre renvoie des données structurées. Chaque appel a été écrit à l'avance par un développeur. » et de « middlewareLa couche intermédiaire qui permet aux systèmes de communiquer entre eux. », le client pense à « faire en sorte que tout fonctionne ensemble ». Ce travail de traduction échoue régulièrement. Pas par mauvaise volonté de part et d'autre, mais parce que personne n'a pour mission explicite de parler les deux langues et de faire le lien.

Le budget face à la réalité

Nous le voyons trop souvent : des fournisseurs qui remettent sciemment un prix trop bas pour décrocher le marché, en espérant que les travaux supplémentaires compenseront plus tard ce qu'ils sous-facturent aujourd'hui. Et des clients qui pensent que des systèmes complexes peuvent se construire pour trois fois rien. Ce mélange de prix fondés sur des vœux pieux, des deux côtés, est une bombe à retardement.

Un projet sans véritable propriétaire

Les deux parties se renvoient la balle. Le fournisseur dit : « Le client livre ses informations trop tard. » Le client dit : « Ils auraient dû le prévoir. » Pendant ce temps, le projet s'enlise. Sans quelqu'un qui veille sur l'ensemble, tout grand projet finit par s'enliser de cette façon.

Notre rôle chez Make IT So

Jan et moi avons fondé Make IT So avec la conviction qu'il fallait faire autrement. Nous n'intervenons pas comme fournisseur, mais comme gardien. Quelqu'un qui défend les intérêts du client face à toutes les parties concernées. Nous sommes du côté de nos clients, pas de celui des fournisseurs. La plupart des problèmes naissent de l'absence d'une partie neutre qui veille au respect des accords, traduit la communication et centralise la responsabilité du projet. Si personne n'occupe ce rôle en interne, nous prenons le relais.

Les signaux concrets que votre fournisseur court à l'échec

Trois phases que nous voyons revenir sans cesse :

  1. Semaines 1 à 4 : la lune de miel. Tout semble bien se passer. Beaucoup de réunions, beaucoup d'optimisme, peu de résultats concrets. C'est la phase où le périmètre dérive sans que personne s'en aperçoive.
  2. Semaines 5 à 12 : les premières fissures. Les démos deviennent plus vagues. Des travaux supplémentaires sont annoncés. Le planning commence à glisser. Si vous ne redressez pas la barre à ce stade, les choses tournent vraiment mal.
  3. Semaine 13 et au-delà : la crise. Le budget est dépassé, le planning aussi, et le fournisseur pointe du doigt le client tandis que le client pointe du doigt le fournisseur. C'est souvent là qu'il est trop tard pour sauver le projet sans de lourdes pertes.

Vous reconnaissez ce schéma ? Il est temps d'intervenir, pas d'attendre que tout soit bloqué. Intervenir tôt est plus difficile sur le plan émotionnel (vous avez déjà investi), mais 80 % moins cher.

Comment éviter ces pièges ?

  1. Commencez par un cadrage solide. Des accords limpides sur ce qui est attendu. Qu'est-ce qui fait partie du périmètre, et qu'est-ce qui n'en fait pas partie ? Qu'est-ce qu'une livraison réussie ? Quels groupes d'utilisateurs devront travailler avec le système ? Prenez le temps de tout passer en revue dans les grandes lignes avant que la moindre ligne de code ne soit écrite.
  2. Prévoyez un gardien neutre. Quelqu'un qui n'a aucun intérêt financier à faire grossir le projet, mais qui a l'expertise nécessaire pour veiller à la qualité. En interne, ce peut être un chef de projet expérimenté ; en externe, c'est un rôle que nous assumons régulièrement.
  3. Des paiements échelonnés liés à des jalons. Ne payez jamais tout à l'avance. Liez les paiements à des fonctionnalités concrètes livrées, pas au temps passé. Cela seul évite déjà une bonne part de la dérive du périmètreL'élargissement discret d'un projet jusqu'à ce qu'il devienne ingérable..
  4. Des réunions hebdomadaires avec des livrables concrets. Pas de vagues nouvelles du genre « nous avançons bien », mais des démos concrètes de ce qui a été livré dans la semaine. Si la démo ne peut pas avoir lieu, c'est cela, le statut : rien de concret n'a été livré.
  5. Un plan B dès le premier jour. Que se passe-t-il si le fournisseur disparaît ? Comment reprenez-vous le projet ? Ces questions semblent négatives, mais elles obligent à clarifier qui est propriétaire du code, des données et de la documentation. Un point à ne pas négliger non plus dans le contrat.

Le côté humain des partenariats IT

La technologie en soi est rarement le problème. Il s'agit de personnes qui doivent collaborer avec d'autres personnes, et c'est souvent là que ça coince. Les fournisseurs sont sous pression pour décrocher des contrats et s'attardent parfois plus longtemps dans un projet qu'il ne le faudrait. Les clients sont frustrés par les dépassements de budget et les retards, et cette frustration les pousse à repousser le fournisseur plus loin que ce qui est utile.

Chez Make IT So, nous essayons d'être le trait d'union. Nous parlons les deux langues : celle du métier et celle de l'IT. Nous comprenons la pression qui pèse sur les fournisseurs, et nous comprenons la frustration des dirigeants confrontés aux dépassements. Tout s'arrange avec du temps et une communication honnête. À condition que chacun soit prêt à prendre ses responsabilités, bien sûr.

Vous avez des doutes sur votre partenariat IT actuel ou vous êtes face à une nouvelle sélection ? Un second avis donné par un acteur indépendant qui accompagne votre numérisation coûte toujours moins cher que les trois mois de crise que vous risquez sans cette deuxième lecture.