Crash de l’AF447 et les limites de l’informatique embarquée

DEUXIEME PARTIE (SUITE)

=====================

==== Baisser le COUT de la MAIN D’ŒUVRE ==== :

Cela s’est fait d’une part par la délocalisation, ce qui a entrainé ipso facto une diminution du prix mais aussi une diminution de la qualité. non pas que les informaticiens off shore soient plus mauvais, mais tout simplement ils ne sont pas formés aux méthodes, ne connaissent pas le niveau de responsabilité que nous connaissons (regardez le « i ») et ont donc implémenté, a leur sauce, des produits complexes... et d’autre part, par l’embauche de « jeunes » débutants (moins de 2 ans d’expérience) et leur affectation sur des projets a haut risque. Ces armées de programmeurs de qualité inégale ont eu sur les bras des travaux au delà de leur expérience, cas aggrave par l’encadrement défaillant. je m’explique sur ce point...

L’encadrement coutant plus cher, le nombre et la qualité a fortement baissé. Là ou on comptait moins d’une dizaine d’ingénieurs pour un chef de projet s’est transformé en 20 et plus de jeune nécessitants un support accru vue leur expérience. Le traitement de la qualité (un ingénieur dédié par projet), l’intervention de consultants… tout ce support a la création a fondu laissant la place a des Template et/ou des logiciels d’avancement de projets qui ne remplace évidement pas la compétence des spécialistes.

De plus, les cadres chargés d’assumer les responsabilités techniques, administratives de ces projets n’échappent pas a ma vindicte. Dans la plupart des SSII, ce sont les moins bons qui résistent aux purges. Pendant que les personnes compétentes sont « au charbon » c’est-à-dire sont chez les clients en train de bosser, eux, jamais choisis ni réclamés par les clients restent dans les couloirs de leur entreprise et développent des capacités d’influence significative. Il est a lors pour eux aisé de se maintenir et de progresser dans les hiérarchies diffusant leur incompétence et éliminant tous ceux qui les connaissent bien et qui pourraient leur faire un peu d’ombre.

Enfin, la complaisance des procédures de recettes, éminemment liées aux conditions contractuelles de ces projets sommes toutes juteux n’est pas a ignorer non plus. Entre copain, on ne va pas « rejeter » des process complets, même s’ils sont bancals et si des équipes discrètes autant que réduites vont faire leur possible pour en bricoler le fonctionnement jusqu’à l’acceptabilité vraie.

===== Baisser la DUREE de fabrication =====

C’est la un domaine que peu de personne imagine, mais La France a été un des leaders mondiaux dans la réalisation de logiciel. Cela a été du a différents facteur dont un fut majeur lié a la qualité de la conception.

Grace a l’application de méthodes très fortes et très solides, les produits ainsi développés dans le contexte des démarches méthodologiques vraiment appliquées étaient d’excellente qualité. Le revers de la médaille est naturellement la lourdeur des opérations de conceptions, leurs durées et la compétence nécessaire des concepteurs, ingénieurs mieux formes, expérimentés et donc plus chers.

La cupidité des SSII qui au départ ont profité pour saigner je ne sais combien de banques d’assurances, d’administrations en leur vendant ces méthodes s’est également traduit par la volonté de ne pas capitaliser les travaux déjà effectués recommençant encore et encore les mêmes études.

Ce qui devait arriver arriva rapidement, les anglo-saxons ont profités pour d’abord récupérer le mécontentement, ont sorti des « raccourcis » méthodologiques développés par leurs propres sociétés, les ont commercialisés (au passage la méthode dominante française était gratuite) et ont lancés des idées séduisantes mais hélas perverses. En prônant le « RAD » Rapid Application Design, ils ont évidement tués les démarches plus complexes. Petit a petit ils ont réussi a vendre des concepts existant déjà dans les méthodes et démarches existantes, mais ils les ont emballés dans leur langue et dans les esprits grâce au relais d’internet qui a joué un rôle déterminant, comme il se doit. Les méthodes dites « OBJET » qui ne sont que des vues faciles du comportement des concepts informatiques ont remplacé les vraies approches conceptuelles, avec naturellement les imprécisions et non homogénéité qui vont avec. (Reportez vous a UML si vous voulez en savoir plus)

Naturellement les SSII ont pu ainsi fourguer leurs équipes de bras cassés, tant au point de vue des forces vives (ingénieurs) trop débutants que de leur encadrements (incompétents et magouilleurs)

Nous en sommes arrivés au point ou aujourd’hui, les entreprises achètent des formations méthodologiques a la bonne gouvernance des systèmes d’information (lisez ITIL) alors qu’ils possèdent déjà tout ça dans les recueils méthodologiques EN FRANCAIS des années 1990.

Au final, les produits logiciels informatiques n’ont rien gagnés en qualité intrinsèques, c’est-à-dire en nombre de bug par ligne de code écrite, c’est-à-dire qu’il persiste autant d’erreur technique a l’intérieur qu’il y a 20 ans, qu’ils sont extrêmement plus lourd et surtout et c’est la le problème et nous revenons ainsi au vol AF 447, leur architecture conceptuelle est probablement mauvaise ou au minimum ne couvre pas l’ensemble du domaine qu’il devrait traiter.

Cet article est intéressant. Je suis désolé de laisser un commentaire en deux parties, aussi long. Le sujet n’est pas simple, mais on ne peut laisser dire que l’informatique embarquée a atteint ses limites.

On peut seulement montrer et condamner les comportements irresponsables d’un modèle industriel qui n’a plus les moyens d’être le maitre chez lui et qui doit composer avec le modèle financier dont, on le comprend bien, la finalité est loin d’être la même.

Je vous remercie de m’avoir lu, j’ai bien écrit un article là, hein

Hélios,

Merci aussi pour cet éclairage qui me paraît assez proche de mon expérience en informatique.

Oui, absolument, on ne répare jamais un processeur. On le remplace. Pas de doute.

S’il y a une défectuosité, cela se découvre assez vit et c’est la chaleur seule par son utilisation qui peut l’altérer dans la suite.

L’informatique dans l’avionique, je ne suis pas spécialiste, mais je suis presque certain que les processeurs n’ont rien à voir avec des 8088 ou même 80386. Un 8088, tout traité ? Là, c’est de la fantaisie, car l’avionique demande une force de calcul qui doit gestionner bien plus d’instructions par unité de temps que dans les années 80.

Intel et les autres s’approvisionnent probablement en Asie. Et en effet, la grande production a fait baisé les prix et la quantité remplace la qualité.

Les logiciels ne font pas exception. On ne paye plus les experts spécialistes, on les envoie à la retraite prématurément, on délocalise en Inde et ailleurs. La culture étant différente, pourquoi cela irait-il mieux ?

Alors, là bas on crée des ingénieurs à la pelle. Mais dans le lots, comme partout, il n’y a que quelques bons qui sortent du lot et qui font tourner les développements. L’armée des autres attendent le chef. Un overhead inouï.

Les processus des logiciels sont diablement plus complexes et en évolution que le hardware pour compléter le tableau.

Cela se passe chez les plus grands, Microsoft compris. On gère à distance le développement. Pour la maintenance des produits, c’est encore plus mal parti. On ne corrige pas les problèmes pour qu’ils ne se reproduisent plus, on fait du cas par cas, en espérant que les problèmes se reproduisent puisqu’on sera payé ad vitam pour les mêmes raisons.

Le sujet n’est pas simple ?

Si, il est limpide et naturel. Quand on ne paye plus, on ne travaille plus avec motivation avec le soucis du travail bien fait. Je ne connais que trop bien cela après 40 ans dans le circuit.

Pour ce qui des avions et de leur sécurité, nous sommes entrés dans une période de turbulance. Les prix ont chuté grâce au lowcost. On joue avec la masse des consommateurs.
Les lowcost sont aussi sûr que sur les vols réguliers, dit-on.
 A quand les contrôles de maintenance encore plus éloignés pour eux ?
On n’a jamais rien pour rien. Règle de base.

« depuis les années 2000 il y a eu une chute considérable de la qualité intrinsèque de TOUS les matériels sans exception » FAUX, globalement la fiabilité progresse !

« on fabrique pour x années, ou x mois et cela NE DOIT PAS durer plus » Tout à fait VRAI mais concernant le matériel professionnel, cette caractéristique est intégrée dans la gestion maintenantce, bref, c’est surtout vrai en ce qui concerne le matériel grand public.