Développeur
« Mais si... 30 ans qu'on fait la même chose, que j'vous dis
! »(1970-2000)
Vous êtes jeune, vous êtes "in", branché, dans
l'coup, contemplant votre projet java d'un oeil tout rapatriant du net votre
dernier composant EJB-XML de l'autre et écoutant d'une troisième oreille votre
lecteur de mp3.
Mais...
Mais il y a ce consultant senior, 30 ans de métier, qui vous
regarde en rigolant depuis une bonne demi-heure... à force, ça vexe.
Alors vous n'y tenez plus, vous vous retournez et
l'apostrophez. Et il commence à parler. Et vous arrêtez votre lecteur mp3.
Et si... et si vous regardiez l'informatique du point de vue
"métier" ? Qu'est-ce que cela veut dire ? Toutes les réponses sont
dans ce témoignage.
Ok, il est long... mais lisez-le tranquillement, vous
verrez... il fait réfléchir, ce témoignage.
Mes "questions" sont en italique rouge.
Les renseignements essentiels de cet entretien sont
soulignés.
30 ans de métier... et vous êtes diplômé en informatique ???
Dans les années (19)70 ?
Et comment, je
l'suis, petit. Deuxième promotion d'un des trois premières écoles d'ingénieur
en informatique de Paris, s'il vous plait. Avant, il n'y en avait qu'une en
France, à Grenoble. Nous étions donc en plein dans ce que l'on appelait à l'époque les ordinateurs de "troisième
génération", celle qui a vu l'apparition des circuits intégrés, de la RAM
et ROM, plus généralement l'avènement des super-calculateurs, immenses monstres
d'acier qui s'étalaient sur des pièces entières.
1970... Comment la France se positionnait vis-à-vis de
l'informatique ?
Bah.. comme pour
beaucoup d'autres sujets : en indépendante (surtout vis-à-vis des américains!).
De Gaule (le général) avait lancé le "plan calcul" (le 18 juillet
1966) qui était là pour s'affranchir des constructeurs américains et aussi pour
fournir des données pour le programme nucléaire naissant.
L'IRIA (Institut de Recherche en Informatique et
Automatique) était créée par une Loi de novembre 1967. Le Pascal venait
d'apparaître en 1969 et en 1970... le parc français d'ordinateurs se montait à
4500 unités.
La seule industrie française dans ce domaine technologique
était Bull... dont la General Electric avait des participations importantes.
30 ans à faire la même chose... mais quelle chose ?
Mais
l'informatique du côté métier, voyons. Vous, les jeunes, vous voyez toujours
l'informatique et ses révolutions, l'objet, Java, CORBA, XML, etc., etc... Mais, lorsque vous
intervenez en mission chez des clients, vous oubliez que le métier de ces-dits
clients n'a souvent pas vraiment subi de révolutions... tout au plus des
évolutions.
Prenons la banque,
par exemple. L'exemple de ses systèmes d'informations (avec les comptes client)
est frappant. Hier comme aujourd'hui, c'est toujours la même chose. D'un côté,
le serveur de données, de l'autre l'utilisateur. Et dès les années 70, avec
l'apparition de la télématique, l'utilisateur a voulu consulter et mettre à
jour ses données à distance, donc en architecture 2-tiers, pour avoir sa
situation de compte à jour!
[Rq : fin 2002, la télématique représente une faible part
des activités des SSII, cf. slide n° 6 de la présentation "Prestataire en
SSII"]
Aujourd'hui, on a
toujours un client léger (applet java, par exemple) d'un côté et un serveur de
données de l'autre. Le troisième "tier" est le middleware qui
distribue les services entre les utilisateurs et gère les transactions ou
encore la charge (load-balancing). Le tout est éventuellement agrémenté d'un
4ème "tier", le serveur de présentation dynamique (ASP, JSP,
PHP4,...) pour rendre le tout plus joli.
4 tiers ??? Ca
n'existe pas 4 fois "1 tiers" ?!
"tiers"
signifie NIVEAUX ! "Tiers" est
un mot anglais!! (synonyme : "level" ou à la rigueur
"layer"). Tu ne vas pas me dire que tu croyais que "tier"
était français, non ???
[cf. Questionnaire Architecture : Layer vs. Tiers]
Hrmpf... non-non,
j'ai rien dis... continuez...
On est donc passé
du VAX AIX, géré par l'administrateur, au client-serveur utilisé par
l'utilisateur, puis à l'intranet-internet, qui exporte le service vers le
"client" final, via une interface pas toujours très bien pensée...
Humpf... Et en plus, entre chaque niveau, on a introduit un gros plat de
spaghetti! En effet, au début, tout était sur la même machine, maintenant, n
couches réseaux viennent se rajouter entre le serveur et le client.
Mais franchement,
la problématique de fond n'a pas vraiment changé. Accéder, mettre à jour,
traiter et présenter l'information.
Et qui avait ces besoins dans les années 70 ?
Mais les même
qu'aujourd'hui, mon gars : les banques! Mais aussi toutes les entreprises qui
centralisaient (et centralisent toujours) leur comptabilité.
Aujourd'hui,
celles qui attirent l'attention sont les B-to-C (Business to Client), mais les
possibilités de connexions sont encore trop faible pour que ce domaine explose
complètement. Seul le soi-disant dépassé minitel arrive encore, en France, a
tiré son épingle du jeu (avec des coûts de consultation payant, même si on
n'achète rien : un coup de génie!) et à rapporter encore des milliards de
francs. [Dixit SVM Janvier 2001 , le minitel génère 95 millions d'appel par
mois et le 3615 (service "Kiosque") rapportent plus de 12 milliards
de francs, dont le quart (3 milliards) sont réservés aux seuls fournisseurs de
services... le jackpot!]
En revanche, le
B-to-B, ça fait 30 ans que ça dure...
Dans votre cas, qui étaient les 2 'B' de 'B-to-B' ?
D'un côté, des
banques, de l'autre nous, une "start-up" avant l'heure, éditeur d'un
logiciel (programme conçu chez nous et qui tournait chez nous, avec astreintes,
garantie de bon fonctionnement, gestion des transactions... ce qui diffère d'un
progiciel, conçu chez l'éditeur mais qui tourne chez le client, comme un Word
ou un Excel).
N'oublions pas
qu'à l'époque, c'était toute l'informatique qui coûtait cher (les programmes
comme les énormes machines). Dans les années 70, les clients ne pouvaient pas
se permettre d'héberger le matériel informatique. Le coût des machines et des
infrastructures pour les accueillir et assurer leur fonctionnement était
prohibitif.
Dans les années 80, les serveurs se retrouvent au niveau
départemental chez les clients (donc dans les grands départements de ces
clients).
Aujourd'hui, vu le faible coût de ces machines, celles-ci se
retrouvent... partout.
Nous faisions de
la gestion de portefeuilles et de contrats, et ce pour 10% des banques de la
place financière française, s'il vous plaît.
Mais, maismais il n'y avait pas encore Internet, à cette
époque ?
Pff... Internet!
On ne l'a pas attendu pour tirer nos propres lignes spécialisées, soit via
Transpac, soit via RTC (moyen de connexion toujours très en vogue par des
internautes actuels frustrés par l'absence de l'ADSL ou de la BLR - Boucle
Locale Radio - ou encore des limitations du câble!).
Cela s'appelle de
la télématique, gamin. En 79, on enfichait le combiné de téléphone sur un
réceptacle adapté de notre terminal de saisie, et pour interroger nos comptes
on gérait nos transactions en commuté... comme le bon vieux minitel!
A quoi ça ressemblait, l'informatique dans les années 70 ?
Ha ça, c'était du
bricolage de haute voltige : j'ai connu la mécanographie classique, avec
l'UNIVAX 32K (évolution de l'UNIVAC).
D'une par, on
n'avait pas d'écran (enfin... ils existaient mais leur usage ne s'est
véritablement démocratisé que dans le début des années 80). Avant, tout se
faisait avec des machines à écrire dotées de la fameuse sphère d'IBM. C'était
les télétypes (TTY) dont les premiers écrans, d'ailleurs, ne faisaient que
reproduire le comportement. Encore dans les films de cinéma d'aujourd'hui(!),
il n'est pas rare de voir des messages s'inscrire sur ce type d'écran avec, en
bruit de fond, un son de machine à écrire!!! (cf. L'informatique au cinéma)
Ensuite, il
fallait savoir gérer les aspects fonctionnels d'une application avec les
aspects techniques du matériel sur lequel elle tournait. En particulier, on devait
gérer la mémoire associative, qu'IBM a popularisé sous le nom de mémoire
virtuelle (et qui est toujours utilisée par les OS actuels).
Enfin, il fallait
alors rentrer une application au chausse-pieds! Si on rentrait tout, il n'y
avait pas assez de mémoire pour tout compiler, donc on découpait l'application
en modules, compilés séparément et qui ne se chargeaient en mémoire que s'il le
fallait... bref, l'équivalent des dll du C++ ou des jar en java.
Certes,
aujourd'hui ces dll ou jar existent évidemment toujours, mais pas pour des
problèmes de mémoire (avec 256Mo minimum, ça commence à aller), plus pour des
raisons de modularité et d'évolutivité : on remplace un composant sans tout
recompiler, ce qui facilite la livraison aujourd'hui... et ce qui nous faisait
gagner du temps à l'époque (où une compilation était loin d'être une petite
opération banale et peu coûteuse en temps). On n'avait droit qu'à une
compilation par semaine sur l'unique machine, et encore uniquement pendant les
TP!
Les TP ? Vous aussi, vous aviez des Travaux Pratiques à
rendre ?
Je n' y crois pas
!!! Y sait même pas ce qu'est du TP !? Temps Partagé, jeune ignorant! Les
quelques machines que nous possédions à l'époque comptaient deux cycles
d'activités bien distincts. D'un côté, en journée, le TP où toutes les
opérations transactionnelles de type client/serveur s'effectuaient. Par
exemple, en journée, tous les clients se connectaient et laissaient une demande
de relevé de compte qu'ils souhaitaient recevoir par la poste dans les jours
suivants. Ensuite, pendant la nuit, les batch prenaient le relais. Ces process
étaient là pour traiter de très gros volumes d'informations (comme, ici,
l'édition de l'ensemble des relevés de compte demandés la veille) afin non
seulement de les éditer, mais aussi de faire des traitements, comme celui de
les classer selon l'adresse des clients, afin que la livraison des relevés par
la Poste s'effectue de manière plus logique géographiquement... et donc moins
coûteuse pour nous.
TP et batch, tels étaient
les 2 cycles de nos machines. Et encore aujourd'hui, le DataWorkflow (flux de
donnés) de type "business" est là pour gérer ces process (alors que
le DataWorkflow de type coopératif gère la vie des documents au sein d'un
groupe, cf. Lotus par exemple).
L'UNIVAX était
essentiellement mono-tache (en théorie, on pouvait faire du multi-process... à
condition de se farcir à la main toute la gestion des interruptions! En
pratique, personne ne s'y risquait). Donc, une compil par semaine, sur les TP.
Et un test par jour. Avec correction directement dans le code machine, donc
dans des zones de patch prévues à cet effet!
Cela veut donc
dire qu'avant la moindre compilation, nous on ré-flé-chi-ssait! Certes, je ne
nie pas le fait qu'il soit aujourd'hui bien plus confortable d'écrire du code,
d'appuyer sur une touche pour compiler en 2 secondes, puis de tester.
Simplement, ce type de comportement poussé à l'extrême fait que j'ai déjà vu
des jeunes écrire des systèmes entiers, packages après packages, sans faire de
véritable tests-unitaires! Les vrais tests n'intervenant qu'en phase
d'intégration... et là en général... tout explose! Voilà ce qui arrive lorsque
l'on pousse la politique de "l'essai - erreur" trop loin. [alors que
pour de gros projet, elle a parfois du bon, cf. Linux! Ce même article rappelle
que la "science informatique" n'en est qu'à ses balbutiement, même en
2002.]
Nos procédés de
tests se devaient d'être bien plus rigoureux et le programme d'être
maintenable. Pour cela, il fallait bien cerner les interfaces fonctionnelles de
chaque composant et veiller aux dépendances.
Dll, modularité, évolutivité, dépendance... que des termes
très actuels!
C'était quoi, votre problématique client-serveur à vous ?
Hé bien, on avait
des traitements à faire sur des données financières, pour n sociétés
différentes, chacune avec leur présentation particulière et leur réglementation
financière propre. En plus, il fallait pouvoir intégrer rapidement les
évolutions de la Loi en matière de finance.
Pour les batch, il
fallait donc avoir des composants suffisamment souples avec un tronc commun
efficace afin de traiter tous les clients en même temps.
D'où des EXIT
(procédures déclenchées à la fin du traitement d'un composant) personnalisées
selon le client, des ressources dynamiques qui se chargent où non, capables de
se neutraliser entre elles en cas de problème, avec toutes les procédures de
récupération sur erreur.
Chaque composant
est ainsi capable de traiter un certain volume de données, et c'était cette
"volumétrie" qui était facturée au client en fonction du nombre de
ses comptes.
Concernant le TP,
l'aspect transactionnel (avec ses points de synchronisation : COMMIT et
ROLLBACK) était géré, au point même que ces points de synchronisations
concernaient le client comme le serveur : ce dernier était, en cas de problème,
était capable de faire son rollback et de prévenir le client afin que celui-ci
effectue également de son côté son propre rollback.
Et la programmation ? Ca a quand même changé, la
programmation, non ?
Moui, m'enfin si
j'ai connu l'assembleur, n'oublions pas que le C et même le C++ sont 2 langages
qui se situent juste au dessus, vous laissant vous dépêtrer avec les pointeurs
et la gestion mémoire.
Si l'objet a apporté une regroupement plus clair
des données et de leur traitements associés, seuls les langages basés sur un
méta-modèle (Smalltalk, Java) apportent un réel plus. Tout le reste n'est que
de l'assembleur masqué et rendu plus pratique. Et encore, Java est faiblement
typé... c'est le règne du "void*" !
Et puis, l'objet,
l'objet... De mon temps, le principe de base était la séparation claire du code
et données! [et cela peut s'illustrer avec ces kangourous mutants!] Et ce pour
d'évidente raison de sécurité, et aussi de portabilité. Lorsque l'on migrait
d'un système à un autre, la procédure était rodée : on bougeait d'abord la base
de donnée, puis les TP, puis les batch. On est ainsi passé au milieu des années
80 de ADABAS (auquel il ne manquait que les jointures) à d'autres systèmes sans
problème.
De toutes façons,
en matière de gestion, COBOL (1958 !) reste le roi, même aujourd'hui en 2001.
[de même qu'un certains nombres "d'anciennes technos, comme nous le
rappelle en 2002 cet ingénieur]
Qwâââ !? COBOL ??? Ca existe encore ?
Comment ça, « ça
existe encore » ??? Mais qu'est-ce que tu crois, jeune galopiot ? Qu'on peut se
permettre, dans la finance, de dire que 1+1 font 1.9999748789978 à cause d'un
processeur récalcitrant ? La notation flottante scientifique n'est pas faite
pour la gestion. Un seul centime de décalage au début d'une opération et ce
sont des millions de francs envolés à la fin.
COBOL, avec son
système de virgule virtuelle, ne travaille que avec des entiers qui viennent se
mettre dans des champs prédéfinis, dont on a précisé le nombre de chiffre de la
partie entière et de la partie décimale. Comme ça, on est tranquille! Enfin
presque, parce que IBM et Intel n'ont pas été foutu de se mettre d'accord sur
la représentation des nombres entiers!!! L'un le code "poids fort, poids
faible", l'autre "poids faible - poids fort".
Et ça passe l'an 2000, ça ???
Mrrmff... Mort de
rire!!! Mais l'an 2000, jeune sot, cela fait plus de 30 ans que l'on s'en
occupe!!! Pourquoi crois-tu qu'il ne s'est finalement rien passé le 1er janvier
2000, hein ? [cf. Y2K : bug or no bug ?]
Comment penses-tu
que l'on codait les dates dans des applications financières dans les années 70
alors que l'on traitait de contrat de prêt sur 30 ans ?... (sisi, 1975+30 >
2000). Toute date était codée en jour. Je crois qu'on devrait avoir un problème
vers 2176, pas avant!
De toutes façons,
le calcul est vite fait : la référence était le 1er janvier 1901 (pour ne pas
avoir à s'occuper de l'année non-bissextile 1900, puisque les années
bissextiles sont celles divisibles par 4 sauf celles divisibles par 100 sauf
celles divisibles par 400, donc 1600, 2000 sont bissextiles, pas 1900 ou 2100).
Le nombre de jours maxi que l'on stocke est 99999. Vous divisez par 365.25
jours et vous obtenez... 273 ans 9 mois et 11 jours. Bon, allez, 2174, j'étais
pas loin.
Mais c'était quoi, alors, toute cette histoire autours de
l'an 2000 ???
Hophophop... pas de conclusion hâtive, s'il
vous plaît...
D'abord, je n'ai
jamais dis que tous les systèmes avaient anticipé cela et codé les dates comme
nous.
Ensuite, le vrai
chantier qui se cachait derrière ce bug, c'était celui de monter une véritable
plate-forme de test, qui reproduise les conditions de la "prod"
(production), avec tous ses flux financier. Y2K n'était qu'une formidable
opportunité de mettre en place un véritable environnement de test qui allait
servir, certes, à tester le passage à l'an 2000, mais qui sert également de
véritable plate-forme d'intégration avant mise en production. Et la mise en
place d'un tel environnement, cela coûte très cher, même si par ailleurs pas
une ligne de code ne doit être réécrite pour corriger le problème du passage à
l'an 2000. [cf. aussi 2K22K1]
Pour reprendre votre propos initial, l'informatique, telle
qu'utilisée par le métier (ici bancaire) n'a pas changé... vous pouvez
détailler ?
Et non ça n'a pas
changé... Tous les traitements de base de mise à jour et d'accès aux systèmes
d'informations bancaires sont toujours inchangés depuis 30 ans, en général en
COBOL (bon, COBOL 2, d'accord) [cf. la blague Y2K : COBOL]
Réfléchissez un
peu sur le nombre de ligne de code qui, en 30 ans, a vraiment été réécrit.
Ce n'est pas
évident de vraiment tout repenser, car il faut déjà arriver à connaître
l'existant. Les Systèmes d'Informations complexes possèdent des fonctions
conçues pour un fonctionnement entre 5 et 7 ans. C'est normal : dans l'industrie,
en principe, on renouvelle son matériel en gros tous les 5 ans, après l'avoir
amorti. Hé bien là, chez les grands clients comme les banques... non! La
plupart de ces vieilles fonctions tourne toujours aujourd'hui.
Or, le problème, c'est que le turn-over des
programmeurs est en gros de 20% tous les 2 ans. La documentation devient vite
périmée au fur et à mesure des modifications induites ne serait-ce que par les
changements de législation financière.
Certes, il existe
dans ces grands groupes des schémas directeurs qui permettent de s'adapter à
des objectifs variables et qui évoluent dans le temps... mais l'investissement
est souvent considérable, le plus simple étant alors de différer les changements
requis!
Donc non seulement
la problématique ne change pas, mais les moyens tant matériels que fonctionnels
n'ont que peu évolué! Les applications récentes se contentent souvent de bâtir
en encapsulant de l'ancien (le legacy [que vous retrouvez présenté dans
l'article Pourquoi l'Architecture ?]). Ainsi, si l'on creuse derrière vos jolis
J2EE sessions et components (Java to Enterprise) ou autres systèmes de
distribution de services et d'applications... si l'on va derrière tout ça, il
n'est pas rare de trouver des accesseurs COBOL! [d'où de gros problème... aussi
pour les architectes]
Cela change
d'autant moins que l'on est obligé de garantir une compatibilité ascendante à
tous les étages... et si la base "marche" (même basée sur des technos
anciennes, mais fiables, robustes et éprouvées), hé bien on ne va pas la
changer juste pour le fun. Le reste de la pyramide des applications
"modernes" est basée dessus!
Mais... cela ne vous tente pas de mettre à jour tout ça :
les techniques informatiques ont quand même évoluées, non ? A moyen terme, il y
gagnerait (au moins en maintenance), non ?
Ha...
l'insouciance de la jeunesse... la passion, tout ça...
Sauf que, petit,
tu oublies une chose. Le client pour lequel tu interviens, son métier, c'est
pas l'informatique, c'est la banque. Et son métier, dont l'origine remonte à
bien avant l'informatique, n'a pas fondamentalement changé. Simplement, sa
société s'est dotée de différents départements informatique, c'est tout.
[Linus Torwalds rappelle d'ailleurs qu'il n'y a pas de
bénéfique intrinsèque dans le changement : on ne peut pas changer juste pour le
plaisir de changer.
Cf. aussi Qu'est-ce qu'un cadre ?]
Je te l'accorde,
le problème de ces grands clients (banque, assurance, centre de comptabilité,
etc.), c'est qu'ils n'ont pas de vision technique à moyen ou long terme.
Toujours dans le domaine technique, s'ils ont des schémas directeur, ils les
ignorent royalement.
Pourquoi ? Parce
que pour ces sociétés, cela ne sert à rien d'investir pour être le meilleurs
(techniquement) dans 5 ans. Ils veulent juste l'être maintenant.
Du coup,
l'informatique n'est tolérée que si :
- elle rapporte tout de suite de l'argent ou,
- elle permet de faire des économies d'échelle (comme le
calcul de la tournée postale des relevés de compte évoqué plus haut).
En plus, comme
chaque département informatique gère son propre budget et présente son propre
bilan, il n'est pas rare de les voir accepter un projet qui ne leur coûte pas
trop cher, même si cela va coûter le double aux départements voisins qui
devront s'adapter au nouveau système!
Et quand bien même
une solution informatique est retenue, sache bien petit que ce n'est pas
forcément la meilleure ou la moins chère. C'est avant tout celle qui est la
plus "irréprochable", c'est-à-dire fournie par le "n°1"
dans son domaine. Même si la solution se révèle mauvaise, personne ne vous
reprochera d'avoir choisi un leader. Alors que si vous choisissez une solution
plus risquée, plus moderne,... et qui se plante, vous sautez avec.
Et ça, crois-moi, on ne le voit pas que en informatique.
L'exemple le plus célèbre reste le choix du standard VHS pour les cassettes
vidéo...
Reste la
question... combien de temps un tel système (basé sur un socle vieux de 30 ans
et empilant des couches technologiques plus récentes) va tenir ? Qui viendra
mettre un coup de pied dans cette fourmilière ?
Toutes ces technologies actuelles, modulaires, dynamiques
pour faire finalement la même chose qu'avant mais de façon distribuée... Et en
plus pour masquer un existant monolithique de 30 ans !...
J'ai un petit coup d'barre moi, tout d'un coup...
Allez petit,
réjouis-toi! Songe à toute la complexité que ces couches successives apportent.
Complexité
qu'Internet a décuplée, avec ses nombreux protocoles et langages (JavaScript,
différent selon les browsers et encore différent des applets java, elles-même
n'ayant rien à voir avec VBScript, le tout utilisant un HTML qui n'est rien
d'autre que du SGML mal formé alors que XML est bien formé, le tout présenté de
façon dynamique par des servlets et JSP, ou encore par de l'ASP ou du PHP4
ou... etc., etc...).
Bref, vous n'êtes
pas prêt de manquer de travail : vous travaillez dans un des rares métiers au
monde qui contribue à sa propre continuation en se créant toujours plus de
problèmes!
Allons jeune Jedi,
ne pas se laisser abattre, tu dois! Comprendre toutes ces architectures
complexes, tu devras. Facturer très cher tes journées d'intervention de
consultant, tu pourras!
[et cela évoque un avis curieusement similaire de ce jeune
ingénieur en 2002]
[Laurent Bossavit, Coach XP fait bien remarquer que
"cela" (- toujours plus de complexité -) est à la base d'un certain
mécontentement général dans ce métier !]
No comments:
Post a Comment