Pourquoi les projets informatiques sont-ils couramment en dérapages comparativement aux projets d'autres domaines ?

Bonjour,

J'aurai aimé savoir à titre personnel pourquoi les projets informatiques sont-ils couramment en dérapages en terme de budget et de délais comparativement aux projets d'autres domaines ?

Merci d'avance



Modifié 1 fois. Dernière modification le 29/09/05 01:16 par Antoine Lariviere.

Bonjour,

Je ne saurais dire si les projets informatiques sont plus en dérapage que dans d'autres domaines. Mais il est vrai qu'il y a souvent du retard, du dépassement de coûts.
Plusieurs points peuvent peut-être expliquer cela.
- l'industrie du logiciel est jeune comparativement par exemple à la construction immmobilière ou automobile. Les méthodes de travail évoluent en permanence, les méthodes de planification également.
Lorsqu'on lance un nouveau projet informatique il n'est pas rare que ce soit avec un nouveau language, un nouvel outil. Il y a toujours un risque puisque les collaborateurs doivent apprendre à s'en servir avant d'être 'productifs'.
Que ce passerait-il sur un chantier si à chaque nouvelle construction, on changeait les machines (nouvelle grue, nouvelle bétonnière...), on changeait les matériaux (plus de béton mais un nouveau truc révolutionnaire que personne n'a encore essayé) ? Je suis a peu près certaine qu'il y aurait du retard...

- le logiciel informatique n'a pas d'existence propre; on travaille dans du virtuel. Nous ne produisons pas d'objet concrêt.
Dès lors le client ne voit qu'un écran dans une fenêtre sur un écran d'ordinateur. Il ne sait pas, ne peut pas vraiment savoir la masse de travail que cela représente. Une correction paraît facile et rapide à faire. Dans la construction, une fois que les fondations sont faites, il est difficile de revenir en arrière. Le client voit immédiatement où est le problème. En informatique non. Les corrections, les demandes de modifications sont fréquentes même en fin de projet, d'où retard.

- Lors d'appel d'offre, il n'est pas rare de vendre un projet avec nettement moins de jours planifiés que la réalité ne le demande. Ainsi on emporte les marchés mais les journées n'ont tout de même que 24 h. et même avec des heures supplémentaires il n'est pas toujours possible de tenir les délais vendus par les commerciaux...

Bonjour,

De la réponse précédente je tire la conclusion suivante : l'industrie informatique est jeune, en mouvement permanent et ses acteurs manquent de méthodes et de compétence de gestion.

Je le vois un peu autrement :
D'abord, il est assez rare qu'une entreprise dispose des compétences en gestion de projet, qui permettraient de cadrer le projet. La plupart des Chefs de Projets sont d'anciens informaticiens, ou des fonctionnels qui n'ont pas été formés à la gestion : définition du périmètre, gestion des coûts et délais, communication, prise de décision, anticipation et gestion des risques (j'en passe). La majeure partie des personnes oeuvrant dans ce domaine ont été formés sur le terrain, ont acquis de l'expérience. Mais cela ne suffit pas à détenir les clefs d'une bonne gestion de projet.

Ensuite, un projet c'est quoi ? C'est une somme d'activités qui est unique, car les personnes sollicités sont souvent différentes, de milieux divers, parce que l'objectif lui même est unique. Dans ce cas, nous avançons toujours au bord du gouffre de l'inconnu. En cela un projet est souvent confronté à des difficultés mal estimées lors de son estimation, ce qui entraine un retard. On le sait, on doit donc le prévoir et le provisionner. Je reboucle donc avec le premier point : un bonne gestion de projet doit permettre de donner une bonne performance au projet.


Pour conclure : L'automobile et l'immobilier ne sont pas exempt de retards. Dans les contrats de vente sur plan il est souvent précisé des clauses spécifiant quels sont les événements qui ne donneront pas lieu à des indémnités de retard de livraison. Si de telles indémnités sont prévues (ce qui est toujours le cas) c'est qu'il y a bien une raison...


Pierre-Alexandre BORNAND, PMP
Axiem, Consultant en gestion de projet

bonjour,

Autre aspect, et non des moindres, la gestion de projet est intimement liée à l'entreprise :
- C'est elle qui définie sa politique de gestion des risques. L'impact en terme de coût de démarrage n'est pas négligeable, en suivi non plus.
- L'adéquation de l'effort de GP à la nécessité du projet et à la richesse créée pour le réalisateur n'est pas des plus simples.
- L'historique de la société compte aussi beaucoup, comme par exemple dans les SSII où il était question de fournir de la main-d'oeuvre et non un produit.
- Le découpage des fonctions de l'entreprise ne permet pas toujours la visibilité de tous les domaines concernés, que ce soit en avant-vente ou en suivi. Ce découpage entraîne des incompréhensions, des lenteurs décisionnelles, qui induisent soit des retards soit des reprises.

Par contre, Une gestion de projet n'a de sens que pour minimiser les risques sur le produit final (et donc pour le client, mais aussi pour l'entreprise qui réalise). Cela induit simplement que l'activité de gestion de projet est la même quelque soit le domaine. Les ajustements sur le domaine d'activité sont ceux en fait des projets eux-mêmes, que l'on capitalise pour gagner du temps et augmenter la sécurité (référentiel).

Enfin, il est utopique de croire que l'on spécifie bien un besoin du premier coup. Superman n'existe pas, nous ne sommes que des hommes, et c'est la gestion de projet (avec le support de la gestion d'entreprise) qui permet justement de faire la coordination des hommes, des moyens, des environnements, des aléas, etc.

Ingénieur Qualité et méthodes

Bonjour,

Je rejoins les auteurs de toutes les réponses précédentes.
La diversité des arguments montre bien que gerer un projet nécessite des compétences pointues.

Malheureusement , même si un projet est bien conçu à la base

- Définition du cahier des charges avec le client ET un consultant
- Analyse des besoins
- Chiffrage du délai de réalisation, des tests,de livraison, validation
- Mise a disposition des compétences et ressources

Il ne faut pas oublier que nous avons des femmes et des hommes en face de nous , au fur et a mesure de l'avancement du projet , des modifications interviennent, des demandes supplémentaires arrivent , qui ne sont pas incluses dans le projet de base.

Or souvent , le client ne retient que l'estimation de temps originelle , sans forcément comprendre l'impact que peuvent avoir ses demandes supplémentaires.

La raison principale est que dans les projets informatiques nous sommes vraiment dans un cas complexe de Gestion de Projet où il y a une décorélation entre le Temps et la Charge.

Sur ces projets les modèles "classique" d'ordonnencement de tâches et d'affectation de ressources ne fonctionnent pas. Ce ne sont pas des projets à mener suivant les logiques des projets industriels bien au contraire.

Car dans les projets informatiques, le plus pénalisant c'est une mauvaise gestion des ressources pas un non respect des dates de livraison.

Dans un projet industriel ou de BTP si vous ne respectez pas les délais, vous subirez de la part de votre donneur d'ordre un malus financier. De plus dans ces projets, le simple fait d'augmenter le nombre de ressources associées à une tâche diminue mécaniquement et dans des proportions similaires le temps de réalisation de la tâche (2 maçons vont globalement plus 2 fois plus vite pour construire un mur qu'1 seul maçon). Le délai et la charge sont linéairement liés.

Dans un projet informatique, le malus financier est lié aux ressources qu'il faut mobiliser sur un projet. Elles sont à la fois rares et chères. Donc un ressources intervenant au mauvais momemt coûte enormèment. De plus, dans les projets informatiques, il est très rare que l'augmentation du nombre de ressources affectées à une tâches est une influence significative sur le délai de réalisation. Le délai et la charge n'ont pas de liaison linéaire.

Cordialement.
Thierry Dupiot

La majorité des intervenants ici, sont des personnes oeuvrant dans la gestion donc aussi peut être un peu éloignés de l'informatique, d'où peut être une vision large du problème.

En tant que programmeur, je vais tenter de vous expliquer au niveau développement informatique pur, l'origine du problème:

-D'abord il faut savoir que la programmation est assez complexe et chaotique. Par analogie avec l'exemple de la construction cité plus haut, il faut savoir que là où dans la construction il faut juste gérer un certain nombre de points établis et formalisés pour tous les types de constructions, dans la programmation, le programmeur a à faire face, bien souvent, toujours a de nouvelles problématiques.
-Ainsi le travail du programmeur reporté a la construction (mettons, la construction d'un monde virtuel par exemple), reviens a envisager toutes les situations possibles, à établir tout l'environnement ainsi que ses paramètres, à réfléchir à toutes les interactions possibles, et à trouver des solutions a tous les problèmes!
Donc par exemple, là où dans la construction on décidera de faire un petit mur, on se contentera, de choisir le matériau adéquate et ceci éventuellement en tenant compte de quelques contraintes usuelles telles que la solidité, la durée de vie, la corrosion, etc..
Ce petit exemple simple serai dans la programmation bien plus complexe, il faudrait définir le mur, prévoir toutes ses réactions possibles, envisager toutes les situations possibles : des insectes l'attaquent, il est impacté par un véhicule, des enfants jouent à la balle dessus, on le graphite, il est inondé....

Donc les programmeurs étant des humains, il est difficile de tenir compte de tout, et couramment on songe à des améliorations, de nouvelles interactions, pas pensés au début. De même, de par la complexité (ce sont souvent des problèmes mathématiques), il est plus facile pour un programmeur de réfléchir au fil de la conception et non en avant projet!

On peut assez comparer le travail du programmeur à celui des chercheurs par exemple en physique (On cherche...).

De plus, la programmation correspond bien souvent des problèmes de logique et relève d’une structure complexe personnelle au programmeur, rendant le travail à plusieurs sur un même module, une même partie, souvent impossible.


-Ensuite il faut bien voir qu’en programmation, certains problèmes d’apparence triviale se révèlent d’une complexité incroyable.

Ainsi par exemple, l’ajout d’une simple zone de texte permettant à l’utilisateur de saisir lui-même un des paramètres du programme, peut au final nécessiter plusieurs heures de travail et des centaines de lignes de codes.


Et au final, le plus important à retenir, est le caractère humain de la programmation, ainsi, bien souvent on peut perdre des heures sur un problème mineur incompréhensible.
Il arrive couramment que l’on perdre une après-midi à chercher sans relâche la cause d’un comportement étrange du programme ou simplement pourquoi une opération simple ne veut pas s’effectuer. Et au final, cela se révèle souvent n’être qu’une erreur tellement ridicule qu’on n’y avait pas pensé, comme par exemple, l’oubli d’un caractère spécial à un endroit du code.


Florent VIARD
Florent.viard@wanadoo.fr -- www.nimd.net
Elève en classe préparatoire aux grandes écoles scientifiques – programmeur amateur.

Ayant travaillé dans des secteurs divers (pharma, militaire, telecom et SI), j'ai retenu une chose : c'est que "Ici, c'est un peu spécial"!
Ce qui veut dire en substance dans l'esprit de ceux qui le dise que "Ici, c'est pas si simple"
Ce qui est vrai, mais ce qui est vrai partout. Le développement est une activité délicate, comme la conception d'un bâtiment sous la neige, une raffinerie avec 2500 km de tuyaux divers, un réseau telecom fait dans la rue, une hélice de sous-marin dont jamais personne auparavant n'avait fait de coulée de ce volume etc.
Donc, je ne donne pas d'excuses particulières aux projets SI avec 3 bemols toutefois:

D'une part, c'est effectivement une science jeune qui fait des erreurs mais aussi des progrès significatifs (voir étude Chaos report, standish group)

D'autre part, c'est un domaine où des intervenants clés : les utilisateurs et en particulier le chef de projet utilisateur, est très souvent un "ignorant "total à la fois de la conduite de projet et de notions d'informatique autres que bureautique

Enfin, il est effectivement difficile d'évaluer l'avancement réel des travaux : c'est virtuel et ce qui reste à faire peut demander des jours ou des mois de développement sans qu'il soit possible d'être toujours certain

En conclusion, un projet informatique c'est un peu plus compliqué, mais quand on veut, c'est tout à fait possible de tenir les délais. Comme partout...

Je ne suis pas du tout certain que les projets informatiques soient systématiquement plus en retard que d'autres projet. J'ai plutôt l'impression qu'aujourd'hui, dans le compromis coût/délais/contenu définissant la notion même de projet, c'est le plus souvent le contenu qui est saacrifié, la capacité d'adaptation étant ensuite demandée à l'utilisateur. Au fond c'st le même problème (incapacité à réaliser ce qui était souhaité dans les délais impartis), mais il apparaît différemment.

En fait, les projets informatiques, que je préfère appeler projets "Système d'Information", présentent un certain nombre de spécificités qui les rendent plus difficiles à prévoir et à suivre que les projets dans d'autres domaines. J'ai beaucoup travaillé sur ce sujet et ne peut le résumer en quelques lignes. Si cela intéresse quelqu'un j'ai fait une communication sur le sujet lors du dernier congrès de l'AFITEP à Paris le 05 Décembre 2005 et je transmettrai le mémoire à qui le souhaite. Je vous renvoie aussi à quelques pages personnelles sur lesquelles je décris un approche permettant dans de nombreux cas de mieux suivre l'avancement des projets SI: [perso.wanadoo.fr]

Concevoir un système d'information, c'est concevoir une autre manière de faire fonctionner une organisation, ce qui sous-entend que l'on soit capable de la modéliser de façon exhaustive : pour le nominal, ça va, on a UML, mais pour les cas particuliers dus au fait que des hommes et leurs organisation ne sont pas des mécaniques, c'est plus dur. Mais ça peut encore aller.

Après, vient la phase de déploiement, et le facteur bloquant devient la capacité des personnes de l'organisation à suivre et à accepter de changer leurs manières de travailler, voire de voir se rééquilibrer leurs pouvoirs respectifs. Et c'est là que se trouvent les retards les plus importants. On essaye bien de travailler nos plans de communication et de formation, mais cela reste très aléatoire.

Mettons des puces dans les cortex de tous les membres de l'organisation, et les projets SI tiendrons leurs plannings.

C'est un petit billet d'humeur, mais qui résume bien les difficultés de plannification en MOA SI ;)

Mon avis de vieux analyste-programmeur (DUT info de 1970) ayant bourlingué en société de services et en entreprise dans le domaine de la gestion.

C'est très simple : j'ai constaté que quelque soit le support utilisé pour développer / tester / valider les programmes et applications, plusieurs paramètres entrent en jeu :

- La connaissance du cadre de développement : entreprise, structures, organistaion, fonctionnement général.

- La connaissance du matèriel et du langage utilisé (je parle d'une expèrience importante en terme de durée).

- L'évaluation de la durée estimée de développement souvent sous-estimée par les commerciaux ou les chefs de projets pour satisfaire les demandes de leurs hiérarchies et se construire une carrière au détriment des "pisseurs de ligne de programme" qui vont s'arracher les cheveux pendant que les décideurs cités plus hauts se contenteront de faire des réunions et des points pour vérifier l'avancement des travaux....et bien sur trouver des responsables pour se décharger de leur propre responsabilité !!!

- Rien n'a changé depuis 35 ans si ce n'est l'évolution de la technique (puissance des ordinateurs et réseaux petrmettant les échanges en temps reél).

C'est un problème HUMAIN : certains sont faits pour tricher sur les délais et ceux qui rament derrière pour se faire "harceler" parce que ça n'avance pas assez vite.

Je me souviens d'avoir fait de la maintenance en un temps très court sur des applications complexes pace-que je connaissais parfaitement les applications pour les avoir concues, développées mises au point..etc, il n'y a pas de secret : l'EXPERIENCE...un point c'est tout. ET C'EST COMME CA QUE JE ME SUIS FAIT VIRER a 49 ANS ALORS QU'ON ME DONNAIT DE + EN + DE MAINTENANCE LOURDE parce-qu'on savait que je serais très efficace, et que je me suis révolté. Ils m'ont bien usé, il n'y aucune question à se poser sur les délais, pour prévoir il faut SAVOIR.

Informatiser c'est automatiser.
Mais automatiser quoi?
Quelque chose qui n'est ni organisé scientifiquement ni stable.
Les sociétés sont des lieux de luttes d'intérêts entre différentes personnes. Ces personnes peuvent établir des ententes souvent implicites et changeantes.
La répartition des responsabilités peut changer en fonction du temps selon des événements extérieurs ou ... l'humeur du Directeur.

Pour mon premier projet à la Commission des Communautés européennes je me suis entendu dire par mon interlocuteur: "pendant 2 ans j'ai réussi à m'opposer à l'informatisation de mon service mais j'ai dû céder devant mon nouveau directeur". Je vous laisse déviner l'aide que nous avons reçu de sa part! Le projet a duré 3 fois plus longtemps que prévu.

Je ne vais pas multiplier les anecdotes, chacun a les siennes.

Trop souvent la hiérarchie se défausse sur l'échelon inférieur en mettant dans ses rapports (cahier de charge ou notes de service) des termes ambigus quand ce n'est pas le silence radio. Alors malheur au programmeur qui hérite de la patate chaude.

En 29 ans de carrière je n'ai connu que 2 sociétés où les choses se passaient corectement: là où la hiérachie suivait les projets de manière sérieuse et où les gens du service Organisation travaillaient avant l'Informatique.

Parce que mettre en place un SI ce n'est pas sans impact sur l'organisation et donc sur répartition des responsabilités entre cadres. Ceux qui se sentent menacer peuvent faire de la rétention d'information pour se protéger et merci pour l'analyste fonctionnel.

L'informatique n'est pas qu'une discipline scientifique, elle demande aussi un solide sens politique.
Pensez-y.

Bonjour, je suis informaticien professionnel

Les projets informatiques prennent beaucoup de retard pour des raisons assez simples :

1) Le manque de processus de réalisation clairement identifiés
Pour un pont, on sait comment on va le faire avant de commencer avec des plans, une architecture.
Il est très étonnant de ne pas voir d'architecture technique clairement définie dans les projets informatiques.

2) L'hypothèse tellement simpliste qu'il n'y a pas besoin de s'y connaitre pour mener le projet à terme.
Quand un pont penche à gauche on trouve une solution à gauche et quand çà penche à droite on trouve solution à droite, le reste s'imagine facilement.

3) La réussite d'un projet est systématisable, c'est à dire que l'on peut réussir des projets informatiques avec un ensemble de technique, processus ou savoir-faire épprouvés.

Il manque beaucoup de lucidité et d'application de techniques rationnelles simples qui ne font pas réver les managers et chefs de projet.

Je crois que j'étais déjà intervenu sur ce forum. Je m'élève sur l'affirmation de base disant que les projets informatiques sont systématiquement en retard, du moins officiellement. C'était vrai il y a quinze ans. Ca ne l'est plus aujourd'hui. Mais pour être à l'heure dans le respect des coûts, les projets informatique font souvent "semblant". Les fournisseurs, comme les maîtrises d'ouvrage, affichent officiellement la fin du projet en jouant sur le flou des spécifications. Ensuite, c'est aux utilisateurs de ce débrouiller plus ou moins bien avec l'outil livré, beaucoup d'ajustement étant effectués dans le cadre de la maintenance.
L'intervenant précédent s'étonne qu'il n'existe pas d'architecture technique précise contrairement à ce qui se fait dans le bâtiment. Le problème, c'est que, à cause de l'évolution rapide des outils, un projet informatique comporte toujours une partie d'innovation. Il s'agit le plus souvent de la mise en place d'un nouvel outil. Le client, au départ, imagine un remplacement à l'identique de son ancien outil puis, découvrant progressivement les possibilités du nouveau, il est naturellement et LEGITIMEMENT amené à modifier les plans de ce qu'il demande, jusqu'à remettre en cause des aspects organisationnels de son travail.
Un projet informatique ne s'apparente pas à un projet industriel mais plutôt à une traversée transocéanique à la voile dans laquelle, en fonction des vents, des courants et de l'état de la mer, il faut toujours réévaluer en temps réel le plan de route. Il existe des méthodes et des approches permettant un tel pilotage. J'ai personnellement beaucoup travaillé sur ce sujet.

Effectivement!!!

Dans un projet informatique, il est bien connu que lors de la rédaction du cahier des charges règne une euphorie certaine, qui laisse place à une légère inquiétude en phase d’études, puis à de la panique en phase de développement. Quand les essais débutent, commence la recherche des coupables bientôt suivie en phase de production par la punition des innocents. Enfin, lors de la phase de mise en œuvre, seuls seront promus ceux qui n’ont pas trempé dans l’affaire!

Mais bon, faut rester optimiste (et ne surtout pas tremper dans l'affaire)

Je trouve ce sujet inquietant et devalorisant pour l'informatique - ou peut-etre s'agit-il de projet IT particulier?

Je suis Directeur de logiciel depuis 10 ans, j'etais responsable d'affaires en engineering mecanique avant pendant 15 ans. Quelques observations:

1. Un projet a plus de chance de reussite quand l'equipe de projet est impliquee au plus tot: chiffrage (estimation du temps) et validation du cahier des charges. Impliquer signifie responsabiliser et souder une equipe sur un meme objectif et travailler sur la synergie (1+1=3, tres vieille formule).
2. Une fois les requirements approuves toute modification doit suivre le meme process: gestion des demandes de modification ou d'amelioration.
3. Il y a toujours du derapage (l'erreur est humaine): gestion des risques.
4. Suivant mon experience, il n'y a pas plus de derapage en informatique qu'en enginering.
5. Risque: Il y a beaucoup moins de risque avec un personnel competent et experimente et encore moins avec une equipe forte - en informatique, au moins 2 ans minimum d'anciennete au poste et meme chose en engineering.

Bonjour,

cela fait 25 ans que je gère des projets ... il y a plus de 25 ans, un monsieur appelé Boehm (prononcer bim, auteur d'un ouvrage appelé "the mithycal man month") a fait l'expérience suivante : il a donné trois mois à des équipes de 2 à 20 personnes pour réaliser le même projet informatique. Toutes les équipes ont eu un mois de retard, et ont produit des résultat "fonctionnellement équivalents" par rapport à la demande.

Plusieurs raisons à cela :
1. la loi des gaz parfaits, qui veut qu'un programmeur utilise tout le temps dont il dispose pour organiser son planning
2. une insuffisance dans la gestion des risques qui fait que l'on ne prévoit pas qu'il y aura des imprévus
3. une meilleur compréhension par les réalisateurs du projet et de sa complexité au fil du temps, ce qui augmente d'autant la charge de réalisation (on n'en profite jamais pour simplifier ...).

Pour information, la dérive moyenne d'un projet est de 20% dans les univers connus (une nouvelle version par exemple), et de 1 à 2 voire 1 à 3 pour les sujets nouveaux.

Cordialement

[www.accompagnement-info.com]

Bonjour,

je me permets d'ajouter mon commentaire aux très nombreux commentaires pertinents de ce sujet :

1) l'informatique a plus de 60 ans maintenant, et ta question, on se la posait déjà il y a plus de quarante ans

2) l'informatique consiste à agiter des électrons pour interagir avec un utilisateur : le nombre de couches successives de technologies pour arriver au résultat est impressionnant, et chacune des couches contribue aux problèmes rencontrés; la dernière, celle qui permet d'interagir avec l'utilisateur, n'est pas la moindre à générer ces problèmes

3) bien que ce problème soit récurrent et connu de tous, on continue à contourner le problème sans vraiment le traiter.

Cordialement

Accompagnement Informatique SAS
Editeur de logiciels de gestion des risques et de mise en place de systèmes Qulaité.

A moi d'ajouter ma petite pierre a l'édifice.

Florent Viard a écrit:
-------------------------------------------------------
> -Ainsi le travail du programmeur reporté a la
> construction (mettons, la construction d'un monde
> virtuel par exemple), reviens a envisager toutes
> les situations possibles, à établir tout
> l'environnement ainsi que ses paramètres, à
> réfléchir à toutes les interactions possibles, et
> à trouver des solutions a tous les problèmes!
> Donc par exemple, là où dans la
> construction on décidera de faire un petit mur, on
> se contentera, de choisir le matériau adéquate et
> ceci éventuellement en tenant compte de quelques
> contraintes usuelles telles que la solidité, la
> durée de vie, la corrosion, etc..
> Ce petit exemple simple serai dans la
> programmation bien plus complexe, il faudrait
> définir le mur, prévoir toutes ses réactions
> possibles, envisager toutes les situations
> possibles : des insectes l'attaquent, il est
> impacté par un véhicule, des enfants jouent à la
> balle dessus, on le graphite, il est inondé....

Sur le principe, je suis d'accord avec cette analogie. A quelques détails prêts...

Les premiers hommes qui ont battis un petit mur, l'ont fait en bois. Mais, ça n'a pas bien résister au feu de camp le premier soir.
Ils ont ensuite reconstruit le mur en terre… il résistait beaucoup mieux au feu, mais pas au inondation de la saison des pluies.
Tout ça a évolué, et aujourd’hui, nous avons des immeubles en béton, acier et climatisés.

C’est la même chose pour l’informatique… au départ, tout était réalisé en assembleur sur des cartes perforées et le programme était dépendant de la machine.
Aujourd’hui, des langages plus évolués permettent d’obtenir des projets indépendants de la plate-forme cible.
Il ne faut pas croire qu’il faut tout reprendre à zéro à chaque fois, en oubliant complètement ce qui a été réalisé sur d’autres projets (module, API, lib, procédure, expérience, etc.)

Pour continuer dans cette analogie, du mur, l’informatique étant virtuelle (donc non matériel par définition), certaine erreur peuvent passer inaperçu si elles sont justifiées correctement (ce qui peut paraître paradoxale)

Reprenons l’exemple du mur et appliquons-le à la construction complète d’une maison.
Une fois les plans réalisés, le chef de chantier va demander à ses ouvriers de poser le toit. Ils seront protéger du soleil et de la pluie quand ils creuseront les fondations.
Le toit fait, l’équipe s’attaque aux fondations de la maison.
Après, il ne reste plus qu’à faire les murs, l’électricité et les canalisations.
Deux choix possibles :
1 – construire les murs, et les détruire partiellement pour faire passer les gaines et les tuyaux
2 – installer les fils électriques et les canalisations, pour ensuite construire les murs autour suivant un chemin déjà bien balisé.

Ils prendront évidemment la deuxième solution.
Devrons doubler les équipes en fin de chantier, pour tenir des délais qui finiront par être largement dépassé.

Evidement, toute ressemblance avec un projet existant ou ayant existé ne serait que pur hasard !

Je ne veux surtout pas rabaisser le métier d’informaticien (architecte, développeur, analyste, etc.), qui est déjà bien souvent malmené. Juste montrer que parfois, une partie du retard sur un projet peut être imputable à une mauvaise organisation. Et là, c’est indépendant de la jeunesse de la science ou des demandes clients : simplement d’une remise en cause de l’équipe.