Pourquoi 70% des projets IT dérapent et comment éviter ce piège

Un ERP à 50 000 € qui finit à 120 000 €. Un site e-commerce livré avec 8 mois de retard. Une application métier abandonnée à 60% d'avancement. Ces scénarios, je les ai vus des dizaines de fois en 15 ans de gestion de projets IT. Le dérapage des projets IT n'est pas une fatalité, c'est un symptôme.

Le vrai problème derrière les échecs IT

Le chiffre de 70% de projets IT en dérapage vient du Standish Group. Mais ce chiffre cache une réalité plus dure : la majorité de ces échecs étaient prévisibles dès le départ.

J'ai accompagné une PME de 45 personnes dans le secteur du négoce. Leur projet CRM devait durer 4 mois pour 35 000 €. Résultat : 11 mois et 89 000 €. Pourquoi ? Le cahier des charges tenait sur 3 pages. Personne n'avait défini ce que "gestion des clients" signifiait concrètement. Chaque réunion apportait de nouvelles demandes. Le prestataire facturait chaque modification.

Le problème n'était pas technique. C'était un problème de cadrage. Pas de périmètre clair. Pas de critères de succès mesurables. Pas de processus de validation des changements.

Ce que dit PMBOK 8 sur la maîtrise des projets IT

Le PMBOK 8 a évolué vers une approche par principes plutôt que par processus rigides. Trois éléments sont essentiels pour éviter le dérapage.

Le principe de valeur avant tout

Chaque livrable doit répondre à une question simple : quelle valeur business apporte-t-il ? Un projet IT qui dérive a souvent perdu de vue cette question. On ajoute des fonctionnalités parce qu'elles sont "possibles", pas parce qu'elles sont utiles.

Valeur projet = (Bénéfices mesurables - Coûts totaux) / Risques acceptés

Si vous ne pouvez pas quantifier les bénéfices d'une fonctionnalité, elle ne devrait pas être dans le périmètre initial.

La gestion adaptative du périmètre

Le PMBOK 8 reconnaît que les projets IT évoluent. Mais évolution ne signifie pas chaos. Le cadre recommande un processus formel de gestion des changements :

Demande de changement → Analyse d'impact (coût, délai, risque) → Validation sponsor → Intégration ou rejet

Chaque changement accepté doit déclencher une mise à jour du budget et du planning. Pas de changement gratuit.

Les jalons de validation

Un projet IT sans jalon intermédiaire est un projet aveugle. Le PMBOK 8 préconise des points de contrôle réguliers avec des critères de passage clairs. Pas de passage au jalon suivant sans validation formelle du précédent.

Application concrète pour une TPE/PME

Vous lancez un projet IT. Voici ce que vous devez faire avant de signer quoi que ce soit.

Définissez 5 critères de succès mesurables. Pas "améliorer la productivité". Plutôt "réduire le temps de traitement des commandes de 45 minutes à 15 minutes". Si vous ne pouvez pas mesurer le succès, vous ne saurez jamais si le projet a réussi.

Listez ce qui est hors périmètre. C'est aussi important que ce qui est dedans. "L'intégration avec le logiciel comptable n'est pas incluse dans cette phase." Écrit noir sur blanc.

Prévoyez une réserve de 20% minimum. Sur le budget et sur le délai. Ce n'est pas du pessimisme, c'est du réalisme. Un projet IT sans imprévu n'existe pas.

Imposez des livrables intermédiaires. Toutes les 3 semaines maximum. Un livrable testable, pas une présentation PowerPoint. Vous devez pouvoir toucher, cliquer, vérifier.

Avec Abema PM, vous pouvez structurer ces jalons et suivre les écarts en temps réel. Mais l'outil ne remplace pas la rigueur du cadrage initial.

Les 5 erreurs qui garantissent le dérapage

1. Faire confiance au devis sans challenger le périmètre. Un devis bas cache souvent un périmètre flou. Le prestataire se rattrapera sur les avenants.

2. Ne pas impliquer les utilisateurs finaux. Le service comptable découvre l'outil le jour de la livraison. Ils détestent. Retour à la case départ.

3. Accepter les changements sans analyse d'impact. "C'est juste un petit ajout." Dix petits ajouts plus tard, le projet a doublé.

4. Payer avant de valider. 50% à la commande, 50% à la livraison. Non. 30% à la commande, 40% aux jalons intermédiaires validés, 30% à la recette finale.

5. Ne pas avoir de chef de projet côté client. Quelqu'un doit suivre le projet en interne. 2 heures par semaine minimum. Sans ce suivi, le prestataire avance seul. Dans sa direction.

Le cas du BTP qui éclaire l'IT

Dans le BTP, personne ne construit sans plans validés. Personne ne paie la totalité avant la fin des travaux. Personne n'accepte de modifications sans avenant signé.

En IT, ces évidences sont souvent ignorées. On démarre avec une idée vague. On paie d'avance. On accepte les dérives parce que "c'est technique, on ne peut pas tout prévoir".

Un projet IT se gère comme un chantier. Plans détaillés. Jalons de paiement. Réception formelle. Les mêmes principes fonctionnent.

Le prochain projet IT que vous lancez peut réussir. Pas par chance. Par méthode. Commencez par écrire vos 5 critères de succès. Si vous n'y arrivez pas en 30 minutes, votre projet n'est pas prêt à démarrer.