C'est un autre paradigme.
Je reprends votre exemple qui force quelque peu le trait. Si un problème est insurmontable, si le prototype est inexploitable ou si la conjoncture rend la solution obsolète, on l'abandonne tout simplement le projet. Le fait qu'une équipe a passé du temps sur un projet en vain est moins grave. La question de retour sur investissement ne se pose pas en terme financier. Pas de risque de mettre la clef sous le paillason: on se fait seulement remonter les bretelles avec une baisse des subventions dans le pire des cas.
Lorsque l'on pense fiabilité il y a peu de chance que sa débouche sur du vapoware. Je distingue deux parties en informatique: ce qui est fonctionnel et qui fait que ça marche et tout ce qui est épi-fonctionnel (choix d'une lib, d'une techno, choix d'un langage, respect de normes, portabilité, modularité, etc...). Dans le militaire, ce qui relève de l'épi-fonctionnel est important mais jamais au détriment du fonctionnel. Peu de chance d'avoir des problème de bug venant du bout de code qui rend le dispositif de frappe nucléaire installable sur mac ou le dernier windows. Mine de rien c'est une sacré charge de travail en moins a court terme. En revanche ça doit se payer lors des migrations si migration il y a.
Enfin le critère de temps a son importance mais jamais au détriment de la fiabilité. Il vaut mieux être quatrième avec un système que l'on ne pénètre pas que premier avec un système plein de failles.
Dans le privé celui qui sort son système plein de failles en premier aura une position de monopole qui lui apportera des fonds. Il proposera éventuellement une série de patch dans un second temps.
Dans le militaire il y a risque que le système se fasse pirater avec peut être un échec et mat en bout de course.
Le privé est victorieux a partir du moment ou il y a vente. Le militaire n'est pas victorieux quand le logiciel est livré mais tant que celui ci tient ses promesses.
Partager