PACBASE en France, le témoignage d’un acteur majeur, Lucien Paternostré

 

LucienPaternostre
Lucien Paternostré (2eme à droite) à La Nouvelle Orléans (1994) avec Alain Glikich (à gauche)

Il est des personnes qui ont marqué profondément PACBASE, parmi elles, Lucien Paternostré qui a donné beaucoup pour le produit.

Après avoir touché à la technique, il fut un des meilleurs commerciaux du produit, avant de créer le support International et de devenir le responsable du marketing.

Témoignage de Lucien Paternostré (Juin 2012).

Avant de présenter mon aventure PACBASE, il me semble important de revenir sur une des grandes spécificités de CGI, sa Culture d’Entreprise.

En effet, je reste persuadé que les sagas Pacbase ou Siga-Gip auraient été bien différentes sans elle  !

CGI, une SSII pas tout à fait comme les autres. Un recrutement varié, de bac + 2 aux plus grandes écoles, qui faisait cohabiter un DEA de géologie, un DEUG de maths, un X, une licence de musicologie (oui, cela existait en 1980…), et quelque fois un informaticien (DUT, MIAGE, …).
Bien entendu la grille de salaire à l’embauche prenait en compte ces différents parcours  !
Toutes ces têtes (bien faîtes, disait la publicité CGI dans les écoles …), quelque soit leur cursus, se retrouvaient ensemble dans la formation initiale de 2 mois.
Corig, Merise, PAC et le reste, cela créent des liens entre les nouvelles recrues, plus tout à fait étudiants, pas encore tout à fait dans le monde du travail, tutoiement, moments forts, souvenirs communs, un des points forts de la culture CGI.
Après ces 2 mois, le grand saut en clientèle, et là aussi pas de ségrégation, ce n’est qu’au bout de plusieurs mois que les parcours évoluaient, et point important, pas exclusivement basés sur le diplôme à l’embauche. Chacun pouvait espérer, un autre des points forts de la culture CGI.
CGI, une SSI pas tout à fait comme les autres, car aussi créateur de méthodes et éditeur de logiciels. La quasi-totalité des interventions en clientèle se faisait auprès d’utilisateurs de méthodes ou/et de produits CGI.
Être salarié de CGI, ce n’était pas être salarié de ……, un autre des points forts de la culture CGI.

Doté d’une licence d’Aménagement du territoire, option Urbanisme, je me préparais à rejoindre une collectivité territoriale (département ou mairie), mais en ce mois de juillet 80, un ami informaticien, connaissant mon fort intérêt pour l’informatique, me parla d’une ‘petite SSI’ de moins de 400 salariés qui recrutait même des non informaticiens.
J’ai donc tenté ma chance. Batterie de tests sous la supervision de Dominique Jamet (RH et même +), entretien avec Alain Gliklich (au cours duquel on parla de beaucoup de chose, mais de mémoire pas beaucoup de travail  !). Et une proposition de recrutement en qualité d’analyste programmeur pour le 25 août 1980.

Donc, 2 mois de formation rue de Grenelle, sous l’égide de François Blick, intervention de tous les responsables de l’époque, au bout de 2 mois nous connaissions les différentes activités de CGI mais aussi assimilé les bases méthodologiques et produits nécessaires et suffisantes pour le grand saut, 2 mois d’ambiance studieuse mais aussi potache, des soirées mémorables, ….

Quelques jours avant la fin de la formation, au moment où l’on devait s’exprimer sur ses souhaits d’affectation, Alain Gliklich (ingénieur en chef et responsable de comptes à l’époque) est venu me dire, tu ne remplis pas les papiers, tu viens travailler avec moi  ! Le lundi suivant, j’étais à la Défense chez Technip pour 18 mois.

A Technip, une petite équipe ‘PAC’ supervisée par Alain était déjà en place, entre autre Jean-François Levi ….. Technip venait aussi de recruter un ingénieur débutant, Pascal Rotilio …  et 10 mois après Richard Martz jeune recrue CGI venait nous rejoindre. Quelques années plus tard, nous nous retrouverons  ensemble au sein de l’équipe ‘Pacbase’.
Technip venait, aussi, d’acquérir Adabas-Natural, superbe SGBD Allemand en avance sur son temps et son outil de programmation temps réel. La guerre était donc déclarée, objectif intégrer Adabas et faire exploser Natural  ! Très rapidement je me suis vu confier la conception et la réalisation des MSP (Macro structure Paramétrable) Adabas. Les premiers programmes PAC utilisant ces MSP étaient aussi et même parfois plus performant que leurs homologues en Natural … A l’usage Natural a donc été réservé pour le développement des programmes jetables (utilisation marginale et très courte dans le temps). Alors que mes collègues travaillaient sur des applications plus classiques, j’étais affecté sur un projet technique ‘les Requis’, Technip, société d’Ingénierie pétrolier construisait des raffineries, il s’agissait là de déterminer automatiquement les besoins en longueur de tube, de nombre de coudes, de boîtes à ressort et j’en ai oubliés, preuve que PAC pouvait être mis à toutes les sauces  !
Alain passait régulièrement faire le point. Pour lui le point (au-delà de la relation commerciale avec le client) c’était la supervision de notre travail, relecture assidue de nos programmes et documentation avec la menace ‘B0’ si le résultat n’était pas bon à ses yeux ou si le nombre de compilation du programme incriminé était trop important (B0, commande PAC pour supprimer toute une arborescence dans une bibliothèque, adieu veaux, vaches, cochons, …). Mais au-delà de cela, le passage attendu d’Alain c’était les nouvelles, nous vivions à travers Alain, la CGI de l’intérieur et plus particulièrement tout ce qui touchait à l’équipe PAC.
Début 1982, après une tentative d’embauche de la part de Monsieur Pinault, directeur des études de Technip, quant Alain me proposa de rejoindre l’équipe PAC, je n’ai eu aucun moment d’hésitation, au revoir Technip  !
A cette époque, comme l’a bien montré Fernand dans les pages ci-dessus, l’équipe PAC se structurait. Alain Gliklich, à côté de sa nouvelle activité ‘croissance externe de CGI avec M Ricolleau, prenait en charge la création de l’activité validation et documentation en vue du lancement du Module Dialogue sous un nouveau label ‘Pacbase’. Alain fit donc appel, comme il le disait, à ses deux erreurs d’embauche, Pierre Olivier Jaques, un an d’ancienneté dont 10 mois comme formateur Pac, pour la documentation et Lucien Paternostré à la validation.
Tout était à faire, ma première mission concernait le module Dialogue, l’objectif (pas forcément atteint) était d’en détecter les éventuels bugs et de faire quelques suggestions d’utilisateur béotien. Mon professeur à l’occasion était Pascal Garrigue, bien plus prof que formateur, il devait bien voir que je ne comprenais pas tout  … mais heureusement Marie Véronique Boile s’efforçait de me décrypter.
Dialogue tournait bien, je me suis donc penché sur les autres modules et là ce sont Bernard Maury et Bernard Decla qui me faisaient cours.
Je n’ai cité que Pascal et les Bernard (les autres voudront bien m’excuser de ne pas tous les citer), mais quelle satisfaction professionnelle, et quelle chance, de pouvoir travailler avec des gens de cette qualité, vous êtes aspiré par le haut, merci à eux.
Au niveau encadrement, notre patron c’était Alain, mais lors de ses nombreux déplacements à l’étranger, nous répondions directement à Bernard Chapot.
Nous commencions la diffusion du produit en Amérique du Nord, pour cela il avait été décidé d’adapter le langage de commande et nous en sommes arrivés à gérer 3 versions de documentation, 1 en Français avec langage de commande français (‘R’ pour Rubrique, …), 1 en Anglais avec langage de commande anglais (‘E’ pour element, …) et 1 en Français mais langage de commande en anglais pour le Québec  !  Cette spécificité ennuyait tout le monde, mais personne n’osait en parler. Lors d’une réunion POJ intervient sur le sujet «  j’en ai parlé avec Bernard Chapot, il est d’accord, on abandonne le langage de commande français  ». Dans la foulée l’équipe technique prend en compte cette info. Bien entendu Bernard n’était pas informé et lors de la réunion hebdomadaire Pascal Garrigue informe de la prise en compte de  cette nouvelle donne. A ce moment Bernard Chapot intervient en demandant pourquoi cela n’avait pas été fait plus tôt  ! POJ pouvait respirer … parfois les évolutions tiennent à pas grand-chose.

Il n’y a pas que le travail, des moments épiques comme celui ou avec Pascal nous sommes allés en camion frigorifique chercher des juke-box que nous donnait Bernard Maury en partance pour les US, ou celui ou Pascal m’a vendu sa DS23I Automatique (très peu d’exemplaires de cette version).
Avec Pierre Olivier Jaques POJ, rapidement les activités se sont croisées, je donnais à POJ des fonctions à valider, lui me donnait de la documentation à relire ou à écrire pour des passages très techniques. Concernant la documentation, à l’époque ou la capture d’écran n’existait pas, nous sommes vraisemblablement les premiers au monde à avoir produit de la documentation technique avec de vraies photos d’écran.
Pour cela nous avions construit une caisse, intérieur peint en noir, ouverte sur le devant, et venant recouvrir un écran passif. A ce moment là nous faisions intervenir Bernard Rouan (grand reporter photo à CGI, en autre activité) qui  photographiait les écrans que nous lui passions. Ensuite avec les clichés développés et la photocopieuse, nous insérions au feutre un cadre simulant l’écran, du grand Artisanat.
Les activités documentation et validation se sont rapidement étoffées, des outils spécifiques ont été développés comme le ‘TNL’, Technical News letter, pour optimiser la diffusion de la documentation et de ses addendums. Les missions ont été élargies  : audit de l’utilisation du produit au Québec, présentation des modules Adabas à Washington, support client à Neuchâtel, ……. etc.
A l’époque, les commerciaux PAC présentaient eux-mêmes le produit, avec l’enrichissement des fonctionnalités ils se sont tournés vers moi pour les démos. Lorsque cette activité a dépassé un plus que mi-temps, il a été décidé de créer le support technico commercial, dont j’ai naturellement pris la responsabilité. En parallèle le monitorat se renforçait avec l’arrivée à sa tête de Pascal Rotilio, débauché de Technip, POJ, quant à lui, quittait la documentation pour aller renforcer l’équipe CGI Systems à Pearl River, Jean François Levi et Richard Martz rejoignaient l’équipe technique l’un à Paris, l’autre à Saint-Nazaire (derrière tous ces changements …. Alain Gliklich).
Des petits jeunes arrivaient aussi à l’équipe technique, Benoît Gloanec, Hichem Jaballah, Yvan Chemama,  puis Jean-Marc Leroux, Maxime Daniel, ….

Au technico, les choses se sont accélérées car l’équipe commerciale Pacbase a doublé, Emmanuel Muyal et Nicole Moreau (ex-responsable de la formation) venant renforcer Jean-Claude Cocquant et Joël Memmi. L’équipe Technico a suivi, Ghislaine Métaireau, Isabelle Moine, en autres, sont venues la rejoindre.  Les ventes se sont accélérées, donc les démos parfois dans des conditions pas faciles. En effet des prospects demandaient des présentations et tests sur leur site. En ce temps là, pas de micro portable supportant Pacbase, nous demandions à France Telecom de tirer une ligne sur Saint-Nazaire ou se trouvait une partie de notre puissance informatique (IBM CICS), nous débarquions avec le matériel, écrans, imprimante, barco, … et quant tout se passait bien, au bout de 2 à 3 jours avec des informaticiens du site, une petite application développée en Pacbase, tournait sur l’ordinateur du prospect, et pour simplifier le jeu, bien souvent la configuration prospect n’était pas celle de Saint Nazaire, IBM IMS, Bull GCOS7 ou GCOS8, …
Les filiales CGI à l’étranger montaient en puissance et naturellement nous leur apportions un soutien en accueillant pendant plusieurs semaines un de leur ingénieur au sein du technico-commercial ou en nous rendant directement chez eux pour ‘un coup de main’ (une petite pensée pour Luc Herdwin).
Depuis plusieurs mois, Joël Memmi patron du commerce Pacbase, me demandait de rejoindre son équipe, j’ai enfin accepté mi 1986 juste après le premier congrès Pacbase à Ouarzazate. C’est au cours de ce 1er congrès que furent jetées les bases du club utilisateurs, le GUEPARD ‘Groupement des Utilisateurs Européens de Pacbase Axé sur les Rencontres et les Développements’. Devant le succès rencontré par Pacbase, avec des clients de tous secteurs d’activité, banque, assurances, industrie, administration, … ,  et dans des configurations informatiques différentes, la création de ce club était devenu une exigence. Pour CGI, afin de structurer les demandes et de ne pas tomber dans les relations privilégiées avec tel ou tel, et pour les clients afin d’orienter les évolutions du produit dans la direction souhaitée par le plus grand nombre et ainsi assurer la pérennité du produit (Le GUEPARD existe toujours aujourd’hui).
Au niveau commercial, la région Ouest France ainsi que quelques grands comptes m’ont été confiés, Aérospatiale, Banque Populaire, …

Un nouveau métier pour moi, Joël, Nicole et Jean-Claude m’ont beaucoup appris. L’équipe grandissant, j’ai été amené à jouer le sénior, en particulier auprès de Kathy Peters qui fait aujourd’hui une carrière brillante au sein d’IBM en Allemagne.
Singularité de CGI, des commerciaux au fixe, pas de commissionnement, ce point était souvent mis en avant auprès des prospects et clients «  notre intérêt, votre satisfaction  ».
En 1989, nous décidons de scinder le commerce en deux, le développement (la chasse) et le suivi clients (l’élevage). Nicole Moreau prend la tête du suivi et moi celle du développement.
L’équipe s’étoffe, Christian Dubois commercial depuis quelques mois décide de me rejoindre et en quelques mois nous sommes une dizaine de personnes. Parmi eux, Gildas Mathurin recruté sur Nantes, qui ensuite a rejoint EUVOXA (SSII de plus de 400 personnes) pour en prendre la Direction Générale et qui aujourd’hui est DGA d’E-Front (société leader sur son marché de la finance, fondée et dirigée par Olivier Dellenbach ex fondateur et dirigeant de Nat-Systems NS-DK, une autre histoire  …) ou Laurence Malroux aujourd’hui CEO d’une société importante aux Etats Unis.
Là aussi, j’ai appris beaucoup avec cette équipe et j’avoue que j’ai parfois été bousculé par les propositions de Laurence comme cette réunion de grands comptes prospects à la Maison de l’Amérique Latine  ; un an après, 2 sur 3 étaient devenus clients  !

Pacbase devenait de plus en plus riche, la station de travail, Pacdesign, Pacbench, PacReverse, Pac/CS dans les startings blocks, et tout le reste, la qualité de service n’était plus tout à fait celle qu’attendaient nos clients. Richard Martz se démenait avec la gestion du planning des développements et il est vrai que le commentaire ‘May Slip’ derrière certaines tâches en faisait bondir plus d’un  ! Pascal Rotilio, responsable du monitorat et de la formation jouait le modérateur avec les clients, … Mi-1992, j’ai donc proposé à Pascal Garrigue de créer le support technique international. J’avais eu l’idée, Pascal m’a donc demandé d’en prendre la responsabilité, j’ai donc quitté le commerce et mon équipe (avec un peu de culpabilité vis-à-vis d’eux).
Fernand a tout raconté de cet épisode, il en était l’un des principaux acteurs avec Jean-François Levi que nous avions réussi à faire quitter l’équipe technique et Alain Destips qui a accepté de s’exiler de long mois à Saint Nazaire.
Période riche et passionnante, qui a été aussi celle, à partir de mi-1993, du rapprochement avec IBM sur la base d’une ‘OPE’ appuyée sur un projet industriel.

‘L’opération de rapprochement entre IBM et CGI Informatique résulte d’une réelle convergence d’intérêt entre deux grandes entreprises et leur offre l’opportunité d’aborder les échéances futures avec une puissance et une volonté renforcées’.

Le GUEPARD s’interrogeait en ces termes  :
«  A plus long terme l’avenir de Pacbase va dépendre de la volonté des uns et des autres d’en faire un outil central dans l’approche AD/Cycle. Si la volonté est d’en faire le standard du marché, cela ne pourra être que bénéfique et permettra d’élargir la palette des logiciels interfaçables avec Pacbase. Tous ces atouts potentiels vont dépendre surtout de la répartition des rôles entre CGI et IBM, …  ».

En interne, et jusqu’au départ de Bernard Chapot, nous y avons cru, nous nous sommes battu, CGI devait devenir le cœur de l’offre ‘IBM GLOBAL SERVICES’..

Au 31 décembre 1994, CGI Informatique, an IBM Company, affichait, un effectif de plus de 4000 personnes, un Chiffre d’Affaires de plus de 2 milliards de francs et un résultat à 2 chiffres.

Christian Nivoix, d’IBM France, a succéder à Bernard Chapot. Malgré son dynamisme et son charisme, le discours ne passait plus. Beaucoup ont changé de poste ou quitté l’entreprise

Fin 1995, j’ai quitté CGI et rejoint Harmonie Mutualité en qualité de Directeur des Etudes. Client CGI/Pacbase, paradoxe de la vie, j’ai développé une stratégie basée sur les progiciels et nous avons quitté Bull pour rejoindre la communauté des utilisateurs IBM AS400. A mon départ, fin 1999, mon remplaçant à la tête des études informatique, Bruno David, était un ancien CGI ……
Je suis resté en Mutualité jusqu’au début 2010, Directeur Général des Mutuelles de Vendée, Directeur Délégué d’Harmonie Mutualité, Président du Directoire d’Harmonie Développement Services, … là encore une vie professionnelle passionnante.
Depuis 2010, je suis consultant en entreprise, encore une nouvelle vie ….

Fernand vous a conté Pac, j’ai tenté de porter un éclairage différent à travers mon expérience et ma sensibilité.
Je pense que vous en êtes maintenant convaincu, quelle chance d’avoir fait un bout de chemin au sein de CGI  !

Merci encore à tous les collègues et clients qui ont jalonnés mon parcours de 16 années et avec qui nous avons vécu ensemble cette belle aventure (qui continue …).

PACBASE aux États-Unis, le témoignage d’un acteur majeur, Gianfranco Moi

GianFranco Moi avec Fernand Bonaguidi à Philadelphie (1994)
GianFranco Moi avec Fernand Bonaguidi à Philadelphie (1994)

Pour compléter l’histoire de PACBASE, il était essentiel de publier le témoignage d’un des acteurs majeurs de l’AGL aux États-Unis, Gianfranco Moi.
Au service des clients durant toute sa carrière, Gianfranco lève le voile sur l’aventure américaine  de PACBASE.
Merci à lui pour ce témoignage indispensable pour comprendre comment l’outil a été perçu et utilisé de l’autre coté de l’ Atlantique, mais aussi en Europe, en Suisse et en Italie..
Témoignage de Gianfranco Moi (Mai 2012).
Nous sommes en mars 1982, je viens de finir mes études à l’École Polytechnique de Lausanne en Suisse.

A la recherche d’un premier emploi en informatique, je réponds à une annonce de CGI qui vient d’ouvrir sa filiale à Genève et cherche des jeunes ingénieurs pour travailler comme analyste programmeur sur le marché local avec les premiers clients PACBASE.

Après une interview avec Vito Lorenzetti, fondateur de la succursale Suisse de CGI, je suis embauché et part immédiatement à Paris pour un stage de formation de 2 mois.
Je n’avais pas conscience alors que cette décision allait conditionner une grande partie de ma carrière professionnelle et de ma vie.

Après ma formation, j’ai travaillé pendant 7 ans avec PACBASE et participé au développement de la filiale Suisse qui s’est rapidement imposée sur le marché Romand mais n’a jamais pu franchir la barrière linguistique de la Suisse Alémanique.

La filiale suisse s’est alors tournée pour son expansion vers le Tessin puis naturellement vers l’Italie, il y a avait plusieurs Italiens, des immigrants de deuxième génération, dans l’équipe CGI Suisse.
La filiale italienne de CGI existait alors déjà depuis plusieurs années mais ne commercialisait pas PACBASE.

J’ai alors commencé à travailler plus directement avec la CGI à Paris où j’ai fait la connaissance de Fernand Bonaguidi et de toute l’équipe de développement PACBASE du Château des Rentiers, pour fournir le support technico-commercial au lancement de cette activité en Italie.

Je venais régulièrement me former à Paris sur les dernières nouveautés du produit avant leur sortie officielle.
Je récupérais des versions Beta, parfois même Alpha, du produit pour faire des démonstrations en Italien avec des écrans en Anglais et les manuels de référence en français …  un vrai «  challenge  », mais passionnant!

A cette époque j’ai beaucoup voyagé pour faire des présentations et du support avant et après vente pour PACBASE dans toute l’Italie où le produit commençait à remporter un certain succès.

Pendant les années 80 la CGI a continué son expansion internationale en créant des filiales ou en rachetant des sociétés en Europe et en Amérique du Nord.

En 1989, PACBASE avait déjà été vendu à plus d’une cinquantaine de clients renommés en Amérique du Nord et la prospection au Mexique venait de commencer.

Aux États-Unis, après un succès initial foudroyant, les ventes de PACBASE ont brutalement chuté car le produit  avait, tout aussi rapidement, acquis la réputation d’être difficile à utiliser.
En fait, les clients américains et canadiens ne trouvaient pas de support pour leurs projets PACBASE car ni CGI Systems, qui commercialisait et assurait la hotline, ni aucune SSII ne fournissaient des prestations de service autour du produit.

Les clients, livrés à eux-mêmes après la formation initiale, rencontraient des difficultés et, ne trouvant pas de support, se décourageaient.

Ils n’étaient pas disposés dans ces conditions à fournir de bonnes références qui sont essentielles pour acquérir de nouveaux prospects.

Il y avait là un «  bug  » dans le business model mais aussi une opportunité à saisir sur le marché Nord Américain.

Constatant le problème, la direction de CGI à Paris décida en 1989 de remédier à la situation en rachetant Matrix Inc., une société de services basée à Philadelphie, qui était en quête d’un acquéreur.
D’autres acquisitions similaires ont rapidement suivi mais les tentatives pour «  booster  » l’ingénierie PACBASE aux États-Unis restèrent infructueuses  ; la «  greffe  » PACBASE ne prenait pas bien sur les SSII américaines.

Devant ce constat d’échec, la direction à Paris, qui tenait à établir et à maintenir une forte présence aux États-Unis en raison du marché mais aussi pour des questions de prestige, proposa à certains employés européens de tenter l’aventure américaine pour renforcer les équipes locales, diffuser la culture d’entreprise et le savoir-faire autour de PACBASE.
En Juillet 1989, je mets donc le cap sur Philadelphie, en Pennsylvanie avec armes,  bagages et ma petite famille pour rejoindre Matrix.

Je ne savais pas alors que je nous passerions 16 ans outre Atlantique.
Après une très courte période d’adaptation je me rends vite compte du problème: les employés de Matrix, comme ses clients d’ailleurs, utilisaient PACBASE pour générer du COBOL.
Le résultat n’était pas mieux que rien mais pire que tout!
Les programmes étaient illisibles et la productivité abyssale.

En caricaturant, mais à peine, pour un programmeur, l’écriture d’un programme PACBASE consistait en un exercice tortueux destiné à contrecarrer la logique générée par le produit pour y faire prévaloir la sienne.

Les analystes programmeurs de Matrix n’avaient pas adhéré à l’idée d’une industrialisation de l’informatique de gestion.

Ils avaient non seulement un certain retard dans ce domaine mais étaient culturellement opposés à une approche structurée du génie logiciel conduisant selon eux au syndrome «  Analysis Paralysis  ».
Ils ne s’attardaient pas dans les phases d’analyse mais se plongeaient rapidement dans la programmation.

Les problèmes de design dans les applications n’étaient pas résolus en agissant sur les éléments du référentiel PACBASE mais solutionnés au cas par cas dans les programmes eux-mêmes.

Beaucoup d’analystes programmeurs avaient d’ailleurs un statut d’indépendant et Matrix ne leur avait donné qu’un vernis minimal pour travailler avec PACBASE.

En général, ils ne maîtrisaient pas bien les concepts.

A ma stupeur, je découvris qu’aux États-Unis PACBASE était en avance sur son temps!
Christian Neau qui encadrait l’équipe des moniteurs de GCI Systems Inc. m’avait envoyé du renfort en la personne d’Emmanuel Hausseguy, un transfuge Français bilingue et expérimenté basé à Pearl River, New York qui s’attela avec moi à l’écriture en anglais d’exemples et des standards pour faciliter l’usage de PACBASE pour les nuls.

Ce complément de documentation sera ensuite connu dans la communauté PACBASE aux États-Unis comme «  Z book  » (clin d’œil à la prononciation à la française de «  The book  »).
«  Z book  » contenait les «  best practices  » PACBASE ainsi qu’une collection de macrostructures et de normes, prêtes à l’emploi, pour bien structurer le «  repository  » PACBASE et son contenu.

Le temps et une démarche systématique auprès des clients nous permit de pérenniser l’utilisation du produit auprès des clients avec qui de très gros projets d’ingénierie PACBASE furent réalisés dans les années 90.

Dans le secteur financier et bancaire pendant la période de consolidation de cette industrie aux Etats-Unis,  PACBASE fut utilisé intensivement par des clients prestigieux comme American Express Financial Advisors, BanK One, Norwest et d’autres.

Dans le secteur public, notamment au niveau fédéral au Department of Defense incluant la Navy et l’Air Force, PACBASE fut utilisé pour écrire une très grande partie leurs applications logistiques de back office.

PACBASE fut aussi été utilisé par AAMVANet pour l’application de recensement et d’harmonisation au niveau fédéral des immatriculations de tous les véhicules à moteur des États-Unis.

Toujours dans le domaine public mais cette fois au niveau des états, PACBASE fut utilisé par le Department of Transportation de l’Ohio pour la réécriture de l’ensemble de ses applications, le département du personnel du Commonwealth of Pennsylvania pour la paie de tous ses fonctionnaires, le State Compensation Fund of Arizona pour l’ensemble de ses applications pour la gestion du fond de prévoyance des employeurs.

Dans les gouvernements locaux des grands contés et des grandes villes comme Phœnix, Chicago, New York, Shelby County, Galveston County et bien d’autres villes et contés, PACBASE fut mis en œuvre pour des développements spécifiques du «  core business» et de «  mission critical systems  ».

Le produit fut aussi vendu à des groupes industriels, a des sociétés de service dont principalement EDS, des assurances, des HMO comme Health Alliance Plan à Detroit qui était l’assurance Maladie de l’Hôpital Ford, etc …

Pendant ce temps j’étais aussi impliqué avec l’équipe de Philadelphie dans la promotion du produit et le support à la vente au Canada avec des clients comme Canada Héritage au Ministère de la Culture, la Police Montée Royale au Canada en collaboration avec Jean-Claude Moïse, le commercial PACBASE canadien, et Banamex, Telmex, et d’autres clients mexicains en collaboration avec Bruno Van Helmerick, le commercial PACBASE mexicain, d’origine française qui parle espagnol comme son nom ne l’indique pas.

A l’an 2000, la  mise à niveau des applications PACBASE pour corriger le «  millenium bug  » se fait en un temps record, 10 fois plus vite que pour les applications traditionnelles COBOL!

Ce qui fait dire à Mike Pachis, alors président du NAPUG (North American PACBASE User Group):
«  PACBASE’s repository was the right idea  !!!».

Je travaillais à cette époque en collaboration avec le centre de compétences Y2K d’IBM à Chicago pour traiter les applications COBOL avec PacReverse pour les des clients qui n’avaient pas encore réécrit toutes leurs applications en PACBASE.

C’était aussi ma première expérience d’outsourcing en Inde avec PACBASE.
Pendant ce temps d’autres produits tels que IEF et IEW s’implantent fortement sur le marché sous le label CASE (Computer Assisted Sofware Engineering) et concurrencent PACBASE.

Avec une approche marketing plus agressive, une interface utilisateur graphique et moins contraignants sur le plan méthodologique, ces produits s’imposent sur le marché au dépend de PACBASE dont l’interface utilisateur commence vraiment à dater.

Le produit ne se vend  quasiment plus aux États-Unis et de moins en mois aussi en Europe.  Ayant de fréquents contacts avec le lab IBM Paris, je réalise que DIVA, qui sera rebaptisé plus tard PAC/CS, ne sera peut-être jamais commercialisé et que nous risquions à moyen terme de perdre nos clients Américains qui insistaient de plus en plus fort pour pouvoir exploiter le contenu du «  repository  » PACBASE pour générer des applications de type Client / Serveur et des applications pour le Web.

Des produits comme Visual Basic, Powerbuilder, puis plus tard VisualAge, mais aussi des suites IDE complètes comme Websphere AD et Eclipse (sa version Opens Source) autour de Java et Visual Studio autour de C# ainsi que d’autres langages font progressivement leur apparition sur le marché et sont rapidement adoptés par les clients.

Nous décidons, avec des moyens très réduits,  de faire une preuve de concept (POC) à Philadelphie pour répondre à la demande des clients PACBASE.

L’idée était simple, faire des développements GUI avec ces nouveaux produits en utilisant le repository et les générateurs de PACBASE pour générer des proxys client et serveur des programmes PACBASE et les faire communiquer par des appels à des middleware du marché comme CPI-C, ECI, Tuxedo, etc. le tout réalisé avec des macrostructures paramétrables.

Finalement réinjecter le code exogène du GUI dans le «  repository  » sous forme de blob pour bénéficier du versioning (Pac Open) … le POC fonctionnait comme prévu fut démontré à la conférence NAPUG en 1992 à Memphis, Tennessee, puis pour Pac Open à La Nouvelle Orléans en 1994..

Le ToolKit permettait de générer des applications modernes avec GUI ou même moderniser les programmes TP de PACBASE avec du GUI ou une interface Web (Pac Web) en utilisant des outils populaires sur le marché. Nous demandons alors au lab IBM de Paris d’industrialiser cette solution appelée provisoirement «  ToolKits  et PacWeb».

Mon ami Fernand Bonaguidi vient me rendre visite à Philadelphie et nous travaillons ensemble pour transférer le savoir faire de Philadelphie à Paris.
Un des développeurs des «  ToolKits  », Jamie Allen est envoyé à St-Nazaire pour effectuer un stage de quelques mois et faciliter leur industrialisation dans PACBASE, et en même temps se former à Pac/CS.

Malheureusement, bien que reconnue comme originale et pragmatique cette initiative contrecarrait les plans de développement en cours du Lab et ne sera pas soutenue par IBM.
Bien plus tard, un concept similaire sera repris par le Lab avec la génération par PACBASE d’un proxy pour VisualAge Generator … malheureusement cela était «  too little too late  !  »

En 1999 je crée ma propre société, e-ASG www.e-asg.com , spécialisée dans la fourniture de prestations et d’édition de progiciels avec PACBASE.

e-ASG, qui a un statut de partenaire IBM, propose des prestations de services, de la formation à PACBASE ainsi qu’une suite complète ERP pour le secteur public livrée dans le repository de PACBASE avec possibilité de génération automatique des écrans sur le Web et une génération des «  reports  » en XML.

Le produit Envision Series avait originalement été développé en LINC, un 4GL de Unisys, par SCI, un éditeur de logiciel basé de St-Louis dans le Missouri.

Nous avions converti Envision Series automatiquement dans PACBASE avec un convertisseur de code très abouti, lui-même écrit en PACBASE, qui prenait en entrée du code LINC et le convertissait automatiquement en entités PACBASE dans le repository.

Ce convertisseur de code avait été développé par mon groupe à Philadelphie dans les années 90 pour les besoins de Lutheran Church Board of Pensions basé à Minneapolis qui voulait migrer ses applications Unisys LINC sur un IBM AS/400.

L’offre de conversion LINC a PACBASE, baptisée «  Lateral Engineering  », fut aussi utilisé par Fisher Price, dans le cadre du rachat par Mattel, pour convertir leurs applications Unisys LINC sur une plateforme IBM mainframe.

D’autres clients Uniys LINC désirant migrer sur d’autres plateformes nous ont approché et nous avons fini par créer un centre de re-engineering LINC à PACBASE à Bangalore, en Inde pour répondre à la demande.
En 2000 IBM discerne à e-ASG l’excellence solution award «  born on the web  » pour Envision Series qui à été mis en œuvre dans plus de 160 gouvernements locaux et districts scolaires aux États-Unis (voir document annexe  : IBM Solution Excellence Award earned by e-ASG for the Envision Series).

Les conférences PACBASE organisées par CGI Systems en collaboration avec le NAPUG réunissaient une fois tous les deux ans, en alternance avec les conférences Européennes, tous les clients en Amérique du Nord, le management de CGI Systems et les équipes de développement PACBASE du Lab à Paris.

Très fréquentées dans les années 80, ces conférences perdaient rapidement de leur intérêt pour les clients dès lors que les annonces de l’arrivée de PAC/CS puis de VisualAge PACBASE se répétaient sans que les produits ne soient jamais livrés.

Les clients d’abord patients, puis impatients avaient finalement perdu patience.
J’ai repris progressivement la responsabilité de la coordination des conférences PACBASE aux USA en collaboration avec le NAPUG, le GUEPARD et le Lab IBM Paris en mettant d’avantage l’accent sur les aspects d’utilisation, les offres de services et les témoignages des clients basés sur leurs propres expériences avec le produit.
Le rapprochement avec VisuaAge Generator à un moment donné a permis d’organiser la conférence PACBASE dans le cadre de la conférence GUIDE d’IBM.

L’idée était de donner une plus grande visibilité à PACBASE en dehors de la communauté restreinte des clients existants.
Cependant, comme le message d’IBM sur le futur de PACBASE était loin d’être clair, l’effet escompté ne fut pas atteint.

A l’occasion de la conférence PACBASE 2002 organisée a St-Augustin, Floride en collaboration avec Mike Pachis, président du NAPUG et Claude Clarisse, président du GUEPARD, nous décidons de faire un recensement mondial des clients et des applications PACBASE ainsi qu’un sondage sur leur attentes afin de communiquer à IBM les priorités des clients et essayer de réorienter les développements PACBASE dans ce sens (voir documents annexes PACBASE Statistics et Lettre conjointe GUEPARD – NAPUG).

Les orientations données par les clients encore nombreux (environ 400 dont 10% en Amérique du Nord) et actifs (globalement 40’000 utilisateurs) étaient claires.
Ils avaient un investissement colossal dans le repository PACBASE avec des millions d’entités PACBASE qui étaient réutilisés en moyenne plus de 3 fois chacune!
Ils souhaitent utiliser PACBASE comme un référentiel unique basé sur un protocole d’échange ouvert utilisant XML, intégré à Eclipse pour tous leurs développements et améliorer l’interface utilisateur du produit pour augmenter la productivité des programmeurs.

Une lettre conjointe du GUEPARD et du NAPUG à IBM précisant ces points, statistiques à l’appui, aboutit à organiser une rencontre de tous les acteurs impliqués qui se tiendra finalement deux ans plus tard à Paris le 29 mars 2005 à la FNCA au cours de l’assemblée Générale du GUEPARD (voir document annexe Assemblée Générale du GUEPARD du 29 mars 2005).

A cette réunion, IBM confirme sa stratégie de convergence VisualAge PACBASE avec Websphere AD, ignore les demandes des clients et annonce la fin des développements PACBASE avec la release 3.5 du produit qui sera maintenue sur le long terme mais sans évolutions majeures  !

Pour moi l’aventure PACBASE s’est arrêtée en 2005 (où presque) quand, pour des raisons familiales nous décidons de rentrer en Suisse où l’on me propose la position de CIO à la Ville à Lausanne.
Poursuivant ma carrière en Suisse, en mars 2012 je suis entré en fonction comme CIO à l’Etat de Genève, succédant à Jean-Marie Leclerc, lui aussi un adepte de la première heure de PACBASE puisqu’il était le premier client Suisse et, pendant de nombreuses années, le président du GUEPARD.

Quelle ne fut pas ma surprise de retrouver à l’État de Genève en 2012 des applications encore en production écrites par CGI en PACBASE il y a environ 30 ans pour une plate-forme Bull  !

«  Interrogez le passé, il répondra présent  !».

PACBASE à été, pour moi, un produit extraordinaire sur lequel j’ai bâti une grande partie de ma carrière professionnelle et qui m’a permis de vivre une belle aventure internationale. Cet aussi grâce à ce produit que j’ai pu côtoyer des individus, eux aussi extraordinaires, comme Robert Mallet, Bernard Chapeau, Didier Roque, Pascal Garrigue, John Swainson, Ian Simpson, Lee Nackman, Pierre Granier, Phlippe Bauquel et bien d’autres que je n’ai pas oubliés mais dont la liste serait bien longue pour la publier ici, sans oublier non plus mon ami Fernand Bonaguidi dont je salue l’initiative d’avoir pensé à écrire ce livre.

Genèse de O+ par Maxime Daniel

Maxime Daniel, le père du Langage
Maxime Daniel, le père du Langage

Au tout début de l’été 1991, le projet AGL89, qui ne s’appelle pas encore PAC/CS, est à la recherche d’un langage de programmation adapté aux systèmes d’exploitation des micro-ordinateurs, et en particulier aux interfaces homme-machine multi-fenêtres, portables entre différentes plates-formes, et assez structurant pour aider nos clients à capitaliser leur parc applicatif au fil des années, dans la grande tradition PACBASE.

Nous disposons alors sur les micros d’un générateur de langages dédiés, qui a fait ses preuves à travers le langage de script de la station de travail Pacbench.

Il présente cependant deux défauts majeurs dans le contexte d’AGL89 :

– c’est un langage fonctionnel pur ; Marc Boullé, moi-même et d’autres collègues pensons que le passage à la programmation orientée objet ne peut pas être différée, et qu’il nous faut un langage orienté objet ; l’expérience des équipes micro de CGI ne fait que renforcer cette conviction, même si les langages orientés objet de l’époque peuvent parfois présenter des caractéristiques peu enviables (l’un d’entre eux utilise le préprocesseur C pour générer à la volée du C qui simule une syntaxe à objets, et présente le curieux défaut que certaines parenthèses des fichiers sources ne doivent pas balancer !) ;

– c’est un langage interprété, ce qui a toujours présenté un certain déficit en termes de performances, à une époque où les performances des systèmes sont très significativement inférieures à celles dont nous disposerons vingt ans plus tard.

Benoît Gloanec décide donc que nous devons développer un langage orienté objet compilé, dont le nom de code sera L89 (pour Langage d’AGL89).

Je me lance dans les spécifications à Saint-Marc, en m’inspirant très fortement de Eiffel. Marc Boullé et d’autres collègues participent très activement à l’élaboration d’icelles, tant en ajouts et affinages qu’en éliminations !

Thibault Le Paul me rejoint et nous commençons allègrement le codage.

Les classes de base algorithmiques (collections, accès au système d’exploitation, etc.), CBA de leur petit nom, sont développées par Bruno Guillon à Paris.

La diversité des systèmes cibles est grande, et la disponibilité de bibliothèques réutilisables portées pour différents systèmes est vue comme un complément absolument nécessaire aux générateurs de code.

Nous nous servons bien entendu de L89 et des CBAs pour écrire le compilateur, empruntant encore à la tradition, qui veut que chez CGI, nous écrivions nos produits avec nos produits à chaque fois que possible.

La plate-forme prioritaire est OS2, le compilateur génère du langage C, vu ici comme « assembleur portable », et le projet avance.

Le 27 février 1992, pris de sérieux doutes, je rencontre Pascal Garrigue rue du Château des Rentiers pour lui exposer que, selon moi, nous n’avons pas les moyens de mener l’aventure à bien (même pas peur !).

AGL89 a besoin de toutes les forces de l’équipe, et mon point de vue est qu’en distraire une partie à élaborer un langage de programmation n’est pas une bonne opération. Je souhaite plutôt que nous mettions en œuvre un langage existant du marché, ce qui aurait l’avantage supplémentaire de doter immédiatement le projet d’un langage complet et équipé de tous les outils et bibliothèques nécessaires.

Compte tenu de leurs caractéristiques respectives, et de notre public, ma préférence va à Eiffel, conçu avec un très grand souci de l’ingénierie du logiciel. (Je juge C++ trop difficile, en particulier pour la gestion de la mémoire, et Smalltalk trop permissif – thèmes que je reprends quelques années plus tard contre ces candidats quand nos clients viennent en formation.En ajoutant toujours « il y aurait bien eu Eiffel, mais… »).

Pascal me « passe un savon » en m’expliquant qu’il faut être fier de ce que l’on fait (ce en quoi il avait parfaitement raison, il faut s’y tenir à chaque fois que c’est possible !), et je rentre à Saint-Marc continuer l’aventure.

L’équipe s’étoffe et le produit grandit et embellit. Nous sommes en 1995 huit personnes à Saint-Marc pour programmer le langage, maintenant appelé O+, ses classes de base graphiques et algorithmiques et son environnement d’exécution.

O+ tourne sur cinq plates-formes (AIX, OS 1.3 et 2.0, Windows 3.11 et DOS 5.0). PAC/CS est codé en O+, qui s’interface aux langages C et C++ pour accéder aux couches les plus basses des systèmes. O+ dispose d’un compilateur, d’un outil de formatage, d’outils variés pour faciliter la détermination des problèmes, par exemple les fuites mémoire.

Nous commençons à rêver de l’intégrer au dictionnaire de façon structurée, abandonnant le format fichier et facilitant au passage l’intégration au modèle de PAC/CS et la conception des générateurs.

Il lui manque en revanche, et pour toujours, des facilités disponibles depuis longtemps pour d’autres langages, comme un débogueur symbolique, et à venir dans les prochaines années comme le complément automatique des noms de classes, méthodes, variables etc. dans les éditeurs de code, la compilation incrémentale et le signalement des erreurs à la volée, et bien d’autres.

S’il faut parler de leçons de modestie, j’évoquerai une bataille homérique entre Marc Boullé et moi sur la pertinence de nous lancer dans la création d’un allocateur de mémoire maison. En 1993, les performances d’AGL89 laissent à désirer, et Marc est convaincu qu’améliorer l’allocateur serait un facteur de gain décisif. Je lui résiste âprement au motif que l’allocateur C, que nous utilisons inchangé, a fait ses preuves, et que rien ne permet de supposer que nous ferons mieux.

Marc code un sous-allocateur chez lui pendant un week-end, et me montre ainsi que j’avais spectaculairement tort. Son prototype met en évidence que, compte tenu de la distribution typique en temps et en taille des allocations et libérations de mémoire d’un langage à objets (allocations et libérations très fréquentes, petites tailles de fragments mémoires radicalement sur-représentées dans l’échantillon), l’allocateur standard du langage C, prévu pour des allocations moins fréquentes et distribuées plus largement, est complètement inadapté. Le prototype transforme les minutes en secondes, sans autre changement.

Thibault Le Paul se lance immédiatement dans la programmation d’un allocateur robuste inspiré des travaux de Marc, que nous étendrons ensuite en ajoutant la détection des débordements et fuites mémoire, des outils statistiques, etc., qui donne un second souffle à toutes les applications écrites en L89, et à AGL89 en premier.

S’il faut parler des moments d’héroïsme, j’évoquerai ce moment tragique fin 1994 où nous réalisons soudainement que Windows 3.11, dont le support est exigé par certains de nos clients, ne supporte pas les segments de données privés.

(Parenthèse pour les gourmands de détails : à cette époque, les DLLs ont des segments de code, où résident les programmes, et des segments de données, où résident les variables ; OS2 permet de distinguer les segments de données partagés, dans lesquels il convient de ranger les constantes, par exemple, des segments de données privés, dans lesquels chaque invocation de la DLL peut ranger, en particulier, ses propres variables ; nous nous retrouvons tout à coup face à une très mauvaise surprise : toutes les copies actives d’une DLL sur un même ordinateur Windows 3.11 partagent leurs variables, les différents programmes modifiant allègrement les données des autres ; inacceptable !)

Les coûts des solutions évidentes sont prohibitifs. Si nous renonçons aux bibliothèques dynamiques, nous allons saturer la mémoire des systèmes, et ne pourrons pas cibler les machines disponibles sur le marché. Si nous devons prendre explicitement des copies différentes des objets par programme, tous les générateurs de PAC/CS (qui génèrent du O+ à partir du modèle et du code spécifique, lui aussi en O+) doivent être réécrits, alors même que nos clients commencent sérieusement à s’intéresser aux versions alpha de PAC/CS.

Bertrand Fayn a alors une idée lumineuse : Windows 3.11 ne supporte peut-être pas les segments de données privées, mais le tout récent processeur 386 d’Intel supporte la segmentation au niveau physique, lui.

Si nous pouvons nous « glisser sous Windows » et piloter la segmentation du processeur à chaque changement de programme appelant pour une DLL, nous sommes peut-être sauvés ! Bertrand commence le travail tout seul et, alors que la piste s’avère en même temps prometteuse et ardue, je lui prête la main.

Nos six mois-homme d’efforts aboutissent à une bonne centaine de lignes de C, et autant d’assembleur, qui constituent le l89swapper, véritable intermédiaire entre Windows et le processeur, qui fait danser les segments physiques pour les DLLs.

Chères lignes, mais PAC/CS tourne comme une horloge sur Windows 3.11, et aucun bogue ne sera rapporté sur ce code critique en neuf mois que durera son existence !

En janvier 1996, nous savons déjà que le développement de PAC/CS est interrompu, et nous n’allons pas tarder à apprendre que, contrairement à ce qui a été annoncé un mois plus tôt, sa commercialisation n’est plus à l’ordre du jour.

Pascal Garrigue m’appelle à Toronto, où je fais mes premiers pas dans la grande famille des laboratoires de développement IBM dans le cadre d’un projet de collaboration, et me confie qu’O+ a été avancé comme l’un des éléments déterminants de la décision d’IBM.

Ce n’est pas un mauvais langage.

Mais c’est un langage propriétaire, que nous n’avons pas les moyens de développer assez largement, ni en fonctions, ni en termes d’adoption sur le marché. Pascal me pose à contre-temps la question rhétorique suivante : combien cela pourrait-il prendre de temps de porter PAC/CS dans un langage qui pourrait recevoir l’agrément d’IBM si l’équipe PAC/CS était restée en ordre de bataille ?

Je réponds un an, peut-être…

La vraie réponse nous échappera toujours.

 

Pacbase, les Hommes en voyage d’affaires

« 1 de 2 »

«Interrogez le passé,il répondra présent»

Raconter Pacbase, le pari peut paraître osé.
Mais il était nécessaire de parler d’un outil qui a traversé 40 ans d’histoire et de l’aventure humaine de passionnés qui se sont succédés pour en faire ce qu’il est aujourd’hui.
Une histoire liée à celle de l’informatique de gestion, dont il fait partie intégrante.
On dit que le futur se nourrit du passé, alors, parlons de ces hommes qui depuis 1972 l’ont aidé à s’enrichir de toutes les technologies pour passer du traitement par lots à l’internet, comme un jeune homme qui ne veut pas vieillir.
Robert Mallet, Bernard Chapot, Bernard Décla, Michel Perretto, Pascal Garrigues, Benoît Gloanec, Jean-Marc Leroux, Lucien Paternostré, Maurice Boudot, Jacques Perronnet, Maxime Daniel, Pascal Rotilio, Jean-François Lévi, Pierre Granier, Philippe Bauquel, la liste est longue et non exhaustive, on aura l’occasion d’y revenir