En développement logiciel, la loi de Pareto se vérifie presque à chaque projet : 80 % d'une application se construit avec 20 % de l'effort, et les 20 % restants (cas limites, erreurs, droits d'accès, données réelles) consomment l'essentiel du temps et du budget. C'est dans cette deuxième phase, invisible en démo, que la plupart des projets dérapent.
Ce phénomène porte un nom chez les développeurs, il se dessine sur un graphique, et surtout il se prévoit. Cet article explique pourquoi le dernier kilomètre coûte si cher, liste de façon aussi exhaustive que possible les détails qui le composent, et montre comment en tenir compte dès le départ.
Qu'est-ce que la loi de Pareto ?
En 1896, l'économiste italien Vilfredo Pareto observe qu'environ 80 % des terres en Italie appartiennent à 20 % de la population. Dans les années 1940, le spécialiste de la qualité Joseph Juran généralise l'idée : dans beaucoup de systèmes, une petite partie des causes produit la majeure partie des effets. C'est le principe des 80/20, présenté en détail dans notre définition de la loi de Pareto.
Le logiciel n'y échappe pas. En octobre 2002, Steve Ballmer, alors patron de Microsoft, écrit dans un mémo interne que les rapports d'erreurs de Windows et d'Office montrent qu'environ 20 % des bugs causent 80 % des erreurs, et que 1 % des bugs en causent à eux seuls la moitié. Le chiffre exact varie d'un projet à l'autre, la forme de la courbe beaucoup moins.
La règle des 90-90 : la version des développeurs
Les développeurs connaissent une variante plus ironique, attribuée à Tom Cargill (Bell Labs) et popularisée par Jon Bentley dans sa chronique Programming Pearls de septembre 1985 :
« Les premiers 90 % du code représentent les premiers 90 % du temps de développement. Les 10 % restants représentent les autres 90 % du temps de développement. »
Le total fait 180 %, et c'est voulu. La blague décrit très bien ce que vivent les équipes : pendant des semaines, le projet avance au rythme prévu, puis il reste « presque fini » beaucoup plus longtemps que prévu.
Sur ce graphique, l'avancement déclaré suit fidèlement le planning jusqu'à 90 %. Ensuite, chaque semaine ne fait gagner qu'un point ou deux. Personne ne ment : le travail restant est simplement d'une autre nature.
Pourquoi les premiers 80 % vont si vite
Au début d'un projet, on construit le chemin heureux : l'utilisateur se connecte, remplit un formulaire correct, valide, et tout se passe bien. Ce chemin est court, prévisible, et les outils modernes l'accélèrent énormément. Un framework comme Django fournit l'authentification, l'administration et les formulaires en quelques heures. Les assistants de code par IA produisent un écran fonctionnel en quelques minutes.
Résultat : au bout de quelques semaines, la démo est convaincante. Les écrans sont là, les boutons répondent, le client voit son logiciel prendre forme. C'est exactement ce que l'on observe avec le vibe coding et le no-code : créer un prototype n'a jamais été aussi rapide, le reste du chemin n'a pas raccourci pour autant.
Ces deux courbes résument le problème. La courbe violette, celle que tout le monde regarde, monte très vite. La courbe orange, celle qui compte le jour de la mise en production, progresse lentement et régulièrement. La surface entre les deux, ce sont les détails.
Pourquoi tout ralentit ensuite : la complexité du détail
Un détail, pris isolément, est presque toujours simple. Gérer un champ vide, prévoir un message d'erreur, empêcher un double clic : quelques lignes de code. Le problème vient de leur nombre et surtout de leurs interactions.
Prenons une application de réservation avec seulement dix règles métier du type oui ou non : client professionnel ou particulier, paiement en ligne ou sur facture, réservation modifiable ou non, etc. Dix règles indépendantes donnent 210, soit 1 024 combinaisons possibles. Il suffit qu'une seule soit mal pensée (un client professionnel qui annule une réservation payée sur facture après la date limite) pour produire une facture fausse, un remboursement oublié ou un stock incohérent.
Les détails ne s'additionnent pas, ils se multiplient. C'est pour cela que la fin d'un projet ne ressemble pas au début : on ne construit plus des écrans, on traite des croisements de cas. Et chaque correction peut en casser une autre, ce qui impose des tests, donc encore du temps.
Conséquence directe : l'effort ne progresse pas en ligne droite. Il est presque plat au début, puis devient quasi exponentiel à l'approche des 100 %. Chaque nouvelle tranche d'avancement coûte plus cher que la précédente, parce qu'elle concerne des cas plus rares, plus imbriqués et plus difficiles à tester.
Dans ce modèle, passer de 90 à 100 % demande à lui seul plus d'effort que tout le reste du projet réuni. Et les 100 % restent un horizon : il existe toujours un cas de plus, un navigateur de plus, une exception métier de plus. Un projet réussi ne vise pas le zéro défaut absolu, il fixe consciemment le niveau de finition attendu pour chaque partie du logiciel.
Un second facteur aggrave les choses : les raccourcis pris pendant la phase rapide. Un code écrit pour la démo, sans structure pensée pour durer, accumule de la dette technique. Au moment d'ajouter les détails, chaque ajout coûte plus cher, parce qu'il faut d'abord comprendre et consolider ce qui existe.
La liste des détails qui font les 80 % de l'effort
Ces détails n'apparaissent presque jamais dans une première estimation. Nous les regroupons ici par famille. Aucun projet ne les rencontre tous, mais chacun d'eux a déjà fait déraper un planning quelque part.
Données et saisie
- Validation de chaque champ : obligatoire, longueur, format, valeurs autorisées
- Formats locaux : numéro de TVA, IBAN, téléphone international, codes postaux, dates au format belge ou américain
- Accents, apostrophes, émojis et caractères spéciaux dans les noms et les adresses
- Doublons : deux fiches pour le même client, deux comptes pour la même adresse e-mail
- Imports depuis Excel avec des colonnes mal remplies, des cellules fusionnées ou des dates en texte
- Reprise des données de l'ancien système, souvent incomplètes ou contradictoires (la migration de données est un projet en soi)
- Volumes réels : une liste qui s'affiche bien avec 20 lignes devient inutilisable avec 50 000
- Historique et traçabilité : qui a modifié quoi, quand, et peut-on revenir en arrière ?
Utilisateurs, rôles et droits
- Rôles et permissions : qui peut voir, créer, modifier, valider, supprimer
- Droits au niveau de la donnée : un commercial ne voit que ses clients, un gestionnaire que son agence
- Invitation, activation, mot de passe oublié, expiration de lien
- Double authentification, connexion via le compte Microsoft ou Google de l'entreprise
- Départ d'un collaborateur : que deviennent ses dossiers, ses tâches, son historique ?
- Plusieurs sociétés ou entités dans le même outil, avec des règles différentes
Cas limites métier
- Annulations, remboursements partiels, notes de crédit
- Modification d'un document déjà validé, envoyé ou payé
- Arrondis de TVA, taux multiples, remises en cascade, devises
- Jours fériés, fuseaux horaires, passage à l'heure d'été, années bissextiles
- Exceptions commerciales : « sauf pour ce client », « sauf ce mois-ci », « sauf si le directeur valide »
- États intermédiaires : brouillon, en attente, partiellement livré, contesté, archivé
Erreurs et pannes
- Double clic sur « Payer » ou « Envoyer »
- Perte de connexion au milieu d'une saisie longue
- Service externe indisponible : paiement, envoi d'e-mails, logiciel comptable
- Paiement refusé, expiré ou remboursé par la banque
- E-mails qui n'arrivent pas, ou qui arrivent dans les spams
- Messages d'erreur compréhensibles pour un utilisateur, et détaillés pour l'équipe technique
Accès simultanés
- Deux personnes modifient la même fiche en même temps
- Le dernier article en stock vendu deux fois
- Un traitement automatique qui tourne pendant qu'un utilisateur modifie les mêmes données
Interface et expérience utilisateur
- États vides (aucun résultat), chargements, pagination, tri et filtres
- Version mobile et tablette, différents navigateurs
- Textes longs qui cassent la mise en page, noms de 60 caractères
- Traductions FR, NL, EN, y compris des e-mails et des documents PDF
- Accessibilité : navigation au clavier, contrastes, lecteurs d'écran
- Raccourcis attendus par les utilisateurs intensifs : recherche rapide, actions groupées, export
Connexions aux autres outils
- Synchronisation avec l'ERP, le CRM ou le logiciel comptable, dans les deux sens
- Facturation électronique Peppol, obligatoire en Belgique entre entreprises depuis le 1er janvier 2026
- Limites imposées par les fournisseurs : nombre d'appels, quotas, changements de version
- Que faire quand la synchronisation échoue à moitié ?
Documents et notifications
- Factures, devis et rapports PDF fidèles à la charte, avec mentions légales
- E-mails automatiques : contenu, fréquence, désabonnement
- Pièces jointes : taille maximale, formats acceptés, stockage
Sécurité et conformité
- RGPD : consentement, export et suppression des données personnelles
- Journal d'audit des actions sensibles
- Protection contre les failles classiques (injections, accès non autorisés)
- Sauvegardes, et surtout tests de restauration
Exploitation au quotidien
- Surveillance, alertes, journaux pour comprendre un problème signalé par un client
- Performances sous charge réelle
- Environnement de test séparé, données de test réalistes
- Mises à jour sans interruption de service
- Écrans d'administration pour que l'équipe métier règle elle-même ses paramètres
- Exports, rapports et tableaux de bord demandés après la mise en ligne
Qualité
- Tests automatisés sur les règles métier critiques
- Recette avec de vrais utilisateurs et de vraies données
- Documentation pour les utilisateurs et pour la maintenance
Pourquoi les projets logiciels échouent
Les chiffres sur les échecs de projets informatiques sont anciens et constants. Une étude de McKinsey et de l'Université d'Oxford portant sur plus de 5 400 projets IT (2012) montre qu'un grand projet dépasse en moyenne son budget de 45 % et ses délais de 7 %, tout en livrant 56 % de valeur en moins que prévu. Le rapport CHAOS 2020 du Standish Group classe 31 % des projets comme réussis, 50 % comme en difficulté (hors budget, hors délai ou incomplets) et 19 % comme abandonnés.
Le chiffre le plus parlant est le troisième. Les délais ne glissent que de 7 % parce que la date de livraison est souvent tenue… en sacrifiant des détails. Le logiciel sort, mais il ne fait pas tout ce qui était attendu. La loi de Pareto explique une grande partie de ces échecs, et elle en déclenche d'autres, plus humains :
- Le devis porte sur les 80 % visibles. On estime les écrans et les fonctionnalités, pas les cas limites. Le budget est calibré pour la première courbe, pas pour la seconde.
- La démo trompe tout le monde. Quand le client voit 80 % de son logiciel après quelques semaines, il en déduit que la fin est proche. L'équipe aussi, parfois.
- Les vraies données arrivent trop tard. On développe avec des données propres et inventées, puis on découvre au moment de la migration des milliers d'exceptions.
- Le budget s'épuise avant la fin. Les détails surgissent en recette, au moment où il ne reste plus de marge. Faute de moyens, on livre un logiciel incomplet ou on arrête tout.
- La fatigue s'installe. Après des semaines bloqué à « 90 % », l'équipe s'use, le client aussi. Les échanges se tendent, la motivation baisse, et les derniers détails sont traités à la va-vite.
- Le client se désengage. Le sponsor interne change de poste, les utilisateurs clés n'ont plus le temps de tester, les décisions traînent. Sans personne pour trancher, chaque détail devient une exigence et le périmètre gonfle sans fin.
- Le développeur disparaît. Un freelance passe à un autre client, un prestataire ferme, un développeur interne démissionne. Celui qui connaissait le code part avec une partie du projet, et son successeur doit d'abord comprendre avant de pouvoir avancer.
Un cahier des charges ne vous protège pas non plus
Face à ces risques, le réflexe est de tout écrire dans un cahier des charges fonctionnel détaillé. Il reste utile, mais il ne protège pas. Il décrit surtout ce que l'outil doit faire quand tout va bien, rarement ce qu'il doit faire quand quelque chose se passe mal. Surtout, il est figé au moment précis où le projet commence à apprendre.
Un projet sur mesure évolue en cours de route, et c'est normal : les utilisateurs découvrent leurs vrais besoins en manipulant les premières versions, une règle métier change, le marché bouge. C'est inhérent au sur-mesure. S'accrocher au document initial produit un logiciel conforme mais inadapté, l'abandonner sans cadre produit un projet qui ne se termine jamais. Il faut donc un cadre clair et de la souplesse : un périmètre priorisé, et des arbitrages explicites quand un besoin nouveau apparaît.
Les économies du début sont les dettes de la fin
En sur-mesure, ce que l'on économise au départ se rembourse souvent à la fin, avec un taux d'intérêt énorme. Un devis serré, un développeur moins cher, un cadrage écourté, des tests reportés « à plus tard » : tout a l'air bien au début, la démo avance vite et le budget est respecté. Puis les intérêts tombent au pire moment, quand il faut traiter les détails, et chaque raccourci rend chaque ajout plus lent et plus risqué. C'est ainsi que des projets qui démarrent très bien finissent mal, ou ne finissent jamais.
Comment tenir compte de la loi de Pareto dans un projet logiciel
Les détails restent inévitables. L'enjeu consiste à les faire apparaître plus tôt et à décider lesquels méritent d'être traités. Concrètement :
- Lister les détails dès le cadrage. La liste ci-dessus sert de grille : pour chaque famille, on se demande ce qui s'applique au projet. C'est l'un des sujets de notre article sur le travail qui précède le code.
- Livrer tôt un parcours complet de bout en bout. Plutôt que dix écrans à moitié finis, un seul parcours réellement prêt pour la production, avec ses erreurs, ses droits et ses vraies données. Il révèle les détails cachés dès les premières semaines.
- Travailler avec des données réelles dès le départ. Un export de l'ancien système, même partiel, vaut mieux que des données de démonstration.
- Utiliser Pareto dans l'autre sens. En général, 20 % des fonctionnalités couvrent 80 % de l'usage. Mieux vaut traiter parfaitement ces 20 % que survoler tout le reste : c'est le principe d'un bon MVP.
- Prévoir explicitement le budget des détails. Une estimation honnête ne s'arrête pas aux écrans. Elle réserve une part importante du temps à la robustesse, aux tests et à la reprise des données.
- Garder de la souplesse dans un cadre. Un périmètre priorisé plutôt qu'une liste figée : quand un nouveau besoin arrive, il prend la place d'un autre ou décale la livraison, et cette décision se prend explicitement.
- Ne pas dépendre d'une seule personne. Un code lisible, des technologies standard, une documentation à jour et au moins deux personnes qui connaissent le projet. Le client reste propriétaire de son code.
- Entretenir l'engagement des deux côtés. Un référent disponible côté client, des démonstrations courtes et régulières, des décisions prises en réunion plutôt que reportées.
- Mesurer l'avancement en parcours terminés, pas en écrans. Un écran affiché peut cacher des semaines de travail, un parcours testé avec de vraies données beaucoup moins.
Chez KERN-IT, c'est la logique que nous appliquons sur nos projets de développement logiciel sur mesure : un cadrage qui liste les cas limites avant de chiffrer, des livraisons par parcours complets, et une décision claire sur ce qui entre dans la première version et ce qui attend la suivante.
Il existe aussi une façon plus radicale d'utiliser la loi de Pareto : ne pas reconstruire les 80 % communs à toutes les entreprises. Comptes et droits d'accès, portails, facturation, notifications, documents générés, historique : nos plateformes métier embarquent ces briques déjà construites et éprouvées en production. Le budget part alors dans les 20 % qui font la différence : vos règles, vos processus, votre métier.
Questions fréquentes
Qu'est-ce que la loi de Pareto en développement logiciel ?
C'est l'observation qu'environ 80 % d'une application se construit avec 20 % de l'effort, tandis que les 20 % restants (cas limites, gestion des erreurs, droits, données réelles, performances) demandent 80 % de l'effort. Elle explique pourquoi un projet semble presque fini longtemps avant de l'être.
Pourquoi mon projet logiciel est-il bloqué à 90 % ?
Parce que les derniers 10 % ne sont pas de la même nature que les premiers : on ne construit plus des écrans, on traite des combinaisons de cas particuliers, et chaque correction doit être testée contre les autres. C'est la règle des 90-90, formulée par Tom Cargill et popularisée en 1985 par Jon Bentley.
Comment estimer un projet logiciel sans sous-estimer les détails ?
En listant les cas limites dès le cadrage, en travaillant avec des données réelles, en livrant tôt un parcours complet de bout en bout et en réservant explicitement du budget à la robustesse et aux tests. Une estimation qui ne porte que sur les écrans visibles couvre rarement plus de la moitié du travail réel.
Un cahier des charges détaillé protège-t-il un projet logiciel ?
Pas complètement. Un cahier des charges fonctionnel décrit surtout le fonctionnement normal et il est figé au démarrage, alors qu'un projet sur mesure évolue toujours en cours de route. La meilleure protection combine un cadre clair, un périmètre priorisé et des arbitrages explicites à chaque nouveau besoin.
