Paru dans Revue de l’Institut International de Géopolitique, N°71, Septembre 2000, Puissance, science et technologie L’industrie du logiciel : les forces économiques et les enjeux stratégiques   J.Printz, Professeur au CNAM

Sommaire

L’industrie du logiciel

• Les catégories de logiciel
• La chaîne de valeur
• La grille d’analyse
• Bilan et opportunités
• La croisée des chemins

Figures

• Figure 1 – Les forces et la dynamique de la compétition
• Figure 2 – Chaîne de valeur d’un système
• Figure 3 – Chaîne de valeur d’une version du logiciel
• Tableau T1 – Profils d’équipes de développement

Il n’est pas aisé de caractériser la puissance économique d’une nation en terme de capacité de production de son " industrie logicielle ". Nous manquons de recul et de données économiques fiables. La notion même d’industrie du logiciel, séparée du matériel ou de son contexte système, est très récente puisque elle voit le jour avec la politique commerciale de " dégroupage " imposée par IBM à ses concurrents du " BUNCH " dans les années 1970.

Le vocable industrie du logiciel recouvre une grande variété d’activités : conception /développement de produits logiciels et/ou de systèmes informatisés clés en main, maintenance corrective et/ou adaptative de logiciels, paramétrage de produits et/ou de systèmes en vue d’un usage adapté aux besoins particuliers d’une personne, d’une organisation, d’une entreprise ; ou encore, installation et exploitation de parcs informatiques, " hot line ", fabrication de " portail " Internet, etc.

Dans les industries traditionnelles comme les matériaux ou l’énergie, on peut se faire une bonne idée de la capacité de production en comptabilisant les tonnes d’acier, les barils de pétrole brut et/ou raffiné, le nombre de mégawatts (hydraulique, thermique, nucléaire), le nombre de véhicules fabriqués, etc. Rien de tout cela ne marche avec le logiciel ! Car le logiciel est immatériel par nature ; il n’est que le reflet des abstractions que le concepteur/programmeur a su faire émerger de la complexité des processus et des systèmes au sens large qui organisent et rythme notre tissu socio-économique. Fabriquer un logiciel est d’abord et avant tout un acte créatif qui matérialise la découverte des abstractions dont on vient de parler. Fondamentalement innovant, non répétitif par essence, évoluant ou, tout au moins, devant évoluer au même rythme que la société au sein de laquelle il se réinjecte, à la fois résultats et données d’entrée d’un nouveau système, on peut concevoir l’extrême difficulté qu’il y a à mesurer une telle capacité de fabrication et/ou d’auto-reproduction. L’auto-référence (le " bootstrap " dans le jargon des informaticiens) est une caractéristique fondamentale de l’information. C’est un vrai défi pour les sciences de l’ingénieur.

Sous sa forme externe visible connue de tous, le logiciel se matérialise comme des textes littéraires, écrits dans des langages dont tout le monde connaît les noms : FORTRAN et COBOL pour les plus anciens, VISUAL BASIC, le couple C/C ++, ou le dernier né JAVA ! Les " phrases " de ces langages, appelées instruction source, sont les ordres que l’ordinateur exécutera, après un traitement approprié par un programme de compilation qui transformera les phrases en instructions binaires seules compréhensibles par la machine.

On peut donc comptabiliser, en première approximation, le nombre d’instructions source mises sur le marché, et utilisées, par tel ou tel pays ; c’est un premier indicateur de production qui n’est d’ailleurs pas une mesure, au sens physique et/ou mathématique.

On a vu, à l’occasion du soi-disant " bug " de l’an 2000, ce que la masse d’instructions écrites qu’il a fallu " toiletter " afin de retrouver tout ce qui pouvait ressembler à une date, représente comme actifs immatériels cachés au sein de notre économie : le coût du " bug " a été évalué  à environ 700 milliards de $ ! essentiellement constitués de coûts humains.

Pour donner une comparaison humainement compréhensible, un système d’exploitation comme GCOS7, développé par Bull dans les années 70-80, totalisait aux alentours de 5 millions de lignes de code source, soit aux normes de l’édition environ 400 volumes de 250 pages ! Avec les annexes documentaires, les divers index qui cartographient cet énorme texte, les instructions machine réellement exécutées, il faut plus que doubler cette taille. Cette masse textuelle donne une petite idée de la difficulté à fabriquer de tels programmes et du savoir-faire indispensable à la maîtrise de la complexité qu’elle renferme. D’où les coûts, exprimé en homme.an (HA), sachant que la productivité moyenne d’un programmeur est, grosso modo, environ 4.000 instructions source documentées, testées et intégrées par an.

A défaut de pouvoir compter les instructions source, tâche très difficile pour des raisons de confidentialité et de propriété intellectuelle, voire souvent par ignorance pure et simple des industriels, on peut essayer de dénombrer ceux qui les fabriquent, c’est-à-dire les concepteurs/programmeurs.

Aux Etats-Unis, par exemple, le nombre d’emplois dans le secteur du logiciel est passé de 0,99 millions en 1993 à 1,60 millions en 1998, soit une croissance de 62% en cinq ans alors que sur la même période ceux du secteur composants/ordinateurs ne croissaient que de 13% pour se situer à 0,61 millions en 1998. Ces chiffres reflètent bien, par ailleurs, l’inversion des coûts du matériel et du logiciel qui s’est produit au cours des 20 dernières années.

Mais est-ce la bonne approche, ou tout au moins une approche pertinente, pour caractériser la capacité de production de l’industrie du logiciel d’un pays donné ? !

Malheureusement non, car en comptabilisant brutalement les lignes de code, ou ce qui revient au même, le nombre de programmeurs, on mélange tout et n’importe quoi. C’est un peu comme si pour caractériser la puissance militaire d’un pays on comptait les porteurs de fusils et/ou de couteaux, ce qui revient à mélanger d’une part les vrais militaires bien formés, qui peuvent agir en groupes organisés au service d’un but de guerre clairement défini, et d’autre part les milices, les bandes armées, voire même les chasseurs de gibiers plus ou moins apprivoisés. Avec ce genre de statistique, rapportée par tête d’habitant il est clair que les Etats-Unis perdraient leur position de première puissance militaire au bénéfice des pays mafieux ou des rogue states.

Pour y voir plus clair, il faut donc rechercher dans le magma des lignes de code source et/ou des programmeurs où est la masse de manœuvre, c’est à dire celles ou ceux qui vont être représentatifs de la vraie puissance technologique et en sont le fer de lance. Une grille de lecture est indispensable. Pour ce faire, nous utiliserons le schéma d’analyse, aujourd’hui classique, de M. Porter qui permet une analyse stratégique des forces qui régissent la compétitivité industrielle.

Ce schéma très général montre que ce qui compte véritablement est l’existence de fournisseurs de produits capables de satisfaire durablement le marché, avec un niveau de productivité, d’innovation et de qualité tel, qu’il empêche l’arrivée de nouveaux entrants et/ou l’apparition de produits de substitution. Ce schéma s’adapte très bien au monde du logiciel. Le pouvoir de Microsoft est son standard Windows-NT, ce qui lui vaut quelques difficultés avec le gouvernement américain. Les " acheteurs " de LINUX créent un contre pouvoir, ce qui permet à RedHat d’entrer sur le marché en assurant une logistique à LINUX. La norme SQL, portée par IBM, permet à ORACLE de démarrer son formidable développement, en tuant au passage une société très prospère comme Cullinet qui avait fondé sa stratégie base de données sur un système de gestion de bases de données (SGBD) sur le parc IBM meilleur que l’offre IBM construite avec IMS/DL1. Le manque d’intérêt et/ou de clairvoyance des fabricants de grands systèmes vis à vis des PC, en particulier d’IBM, font des PCs un substitut potentiel aux mainframes, et ouvre la porte à Microsoft et Intel : sans doute le plus grand bug stratégique de ces vingt dernières années, mais IBM s’est très bien repositionnée depuis ; etc.

Dans l’industrie logicielle, on peut considérer qu’il y a deux grandes catégories de produits qui rentrent parfaitement dans la logique stratégique préconisée par M. Porter :

1. Les produits logiciels, i.e. en plus court les progiciels, multi plates-formes du type WORD, EXCEL, la suite OFFICE de Microsoft, ORACLE, CATIA, les navigateurs, les moteurs de recherche, etc. qui assurent une fonction principale. Ces progiciels ont comme caractéristiques essentielles de pouvoir s’exécuter sur un nombre plus ou moins grand de systèmes d’exploitation, voire quasiment tous dans le cas d’ORACLE. Ils ont vocation à être distribués en très grand nombre, ce qui exige une maîtrise parfaite de la qualité. Dans le cas de logiciels développés pour un besoin spécifique d’une entreprise on parlera d’applications, mais la logique de fabrication est la même que celle du progiciel, en plus simple.
2. Les systèmes informatisés, ou tout simplement systèmes, mono ou multi plates-formes, qui intègrent un grand nombre de fonctions et d’équipements divers et variés, de différentes puissances, en un tout cohérent que l’acquéreur adaptera et/ou programmera, éventuellement à l’aide de progiciels. Dans cette catégorie on trouvera tous les systèmes d’exploitation, les systèmes d’information des entreprises (les ERP comme SAP), les systèmes industriels de contrôle-commande, les environnements de programmation comme le Visual Studio de Microsoft, etc. Certains de ces systèmes assurent des missions critiques d’un point de vue socio-économique, voire stratégique dans le cas des systèmes de défense.

Bien d’autres types de logiciels existent, comme les scripts de paramétrage ou d’administration, les langages de commandes, … mais ils n’ont comme seule raison d’être que l’existence des progiciels et/ou des systèmes qu’ils concourent à faire fonctionner (comme l’huile de nos moteurs de voiture). Derrière chaque bouton, chaque option, chaque fichier,… il y a toujours un programme utilitaire, plus ou moins gros, qui permet d’activer la ou les fonctions correspondantes. Il est tout à fait logique de les décompter à part. IBM, dès les années 70, avait su jouer à fond de cet " effet de parc " en rendant public ses fameux Program Logic Manual qui facilitaient le développement d’une industrie de service (i.e. au service d’IBM ! ). Une telle stratégie crée une barrière de compétitivité qui tue progressivement la concurrence, tout en asservissant à terme les clients, d’où la ruée sur les produits de substitution comme les " serveurs " lorsque ceux-ci sont devenus compétitifs.

Dans les deux catégories ci-dessus, on s’aperçoit que ce qui caractérise la capacité industrielle est la maîtrise du processus de développement du progiciel et/ou du système que l’industriel a su orienter vers la satisfaction de tel ou tel besoin du marché.

Cette analyse par processus est également conforme aux principes généraux exposés par M. Porter dans son ouvrage Compétitive Advantage. Pour ce qui concerne les systèmes et les progiciels, la chaîne de valeur se matérialise comme suit :

Dans cette chaîne, seule la partie Développement et Exploitation est visible du marché. La période correspondant aux phases Faisabilité/Définition peut être très longue : 12 ans pour UNIX, 10 ans pour la norme SQL et l’arrivée des premiers produits SGBD relationnels ; 6-7 ans pour les premiers compilateurs du langage Ada ; etc.

La chaîne de valorisation du logiciel, dont les principaux processus sont connus dès la fin des années 1960, permet de poser et de comprendre où sont situés les vrais problèmes et de formuler quelques observations indispensables à une analyse sérieuse :

Observation N°1 : la partie programmation proprement dite ne représente que 10 à 15% du coût de fonctionnement de la chaîne logiciel, mais beaucoup moins dans la chaîne système, d’où :

• Ramener l’industrie du logiciel à la simple programmation (et à la fourniture de programmeurs généralistes) c’est occulter l’essentiel des coûts et donc se préparer à un échec inéluctable si l’on fonde une stratégie de développement sur ce seul critère. De fait, maîtriser un ou plusieurs langages de programmation n’est pas un exercice difficile et en aucun cas un critère de compétitivité.

* Rechercher une différenciation sur ce simple critère est une vraie faute stratégique.

Observation N°2 : La partie faisabilité du cycle système est le lieu où l’on teste ses idées, en particulier par rapport au besoin du marché et en fonction des capacités des technologies disponibles et/ou en devenir. C’est là qu’il faut être véritablement innovant et sentir le cours des choses, autant dire une activité réservée à une très petite minorité, d’où :

• Fonder une stratégie de R&D uniquement à partir de l’existant, ou de ce qui accompagne l’existant, sans clairvoyance sur le marché, sans lucidité sur les mérites réels des technologies, ou pire, sous l’emprise des modes, c’est se condamner à être toujours en retard et à dilapider un capital qui serait peut-être mieux investi ailleurs.

* Pour entrer sur le marché, il faut une réelle innovation soit comme produit, soit comme service, qui, par définition, n’est pas dans le marché.

Les vrais innovateurs sont très rares et généralement suffisamment débrouillards pour ne pas tout attendre de la manne étatique. En désespoir de cause, ils émigrent aux Etats-Unis, ou se font racheter par des sociétés américaines.

Observation N°3 : La transition de la phase de faisabilité à celle du développement nécessite une étape intermédiaire qui est la phase de définition du produit et/ou du système. Cette phase de tous les dangers, essentielle au développement du produit, est le lieu où l’on détermine la stratégie industrielle, où l’on choisit les technologies et la cible commerciale du produit qui sera développé ultérieurement par incréments successifs. Cette phase est particulièrement délicate car elle est un compromis subtil entre l’innovation, la connaissance du marché, la maturité des technologies et des organisations qui mettront en œuvre ces produits/systèmes.

• Croire, ou laisser croire, que l’on passe à coût marginal de l’idée au produit, ou que les bonnes idées s’imposent d’elles mêmes, c’est faire preuve d’une ignorance totale des lois du marché, de l’histoire des technologies, et prendre de surcroît les décideurs pour des naïfs qui finiront par perdre toute confiance et iront voir ailleurs.

* Entre une maquette de recherche et un vrai produit industriel, le différentiel de coût est dans une fourchette de 10 à 50 !

Face à des objets immatériels comme le logiciel, le bon sens perd ses marques. On peut juger de l’esthétisme, et de la beauté d’un bâtiment sans pour autant être un architecte ou un fin connaisseur des matériaux de construction. Rien de cela n'est possible avec le logiciel où un programme d'apparence anodine peut cacher une formidable complexité combinatoire, ou encore provoquer de terrible nuisance (cf. les " virus " informatiques fabriqués par des gamins ! ).

Observation N°4 : Lorsque l’on est convaincu, ou que l’on a su convaincre, que l’idée est la bonne, après parfois une longue période de maturation, il faut passer le plus rapidement possible au stade de la définition, ce qui requiert d’occulter pour un temps sa capacité créative, mais nécessite surtout de mobiliser rapidement des capitaux dont le pay back n’est évidemment pas garanti.

• Sans une organisation industrielle de développement et sans structure de capital risque efficace, la transmutation de l’idée en produit est vouée à l’échec. Sans une culture entrepreneuriale solide (i.e. droit à l’erreur, reconnaissance et valorisation du risque) personne ne se risquera à ce genre d’aventure.

* Les chefs de projets et les architectes sont des acteurs clés de toute réussite industrielle en matière de logiciel, car le logiciel c’est l’homme ! et non des robots ou des financiers. Il faut les former avec le plus grand soin.

Notons au passage que la vitesse de décision qui caractérise les nouvelles technologies de l’information (NTI) rend ce processus totalement incompatible avec une logique administrative et bureaucratique fondée sur la suspicion. Napoléon disait à ses généraux que " la stratégie est un art d’exécution " ce qui s’applique parfaitement au monde hautement compétitif des NTI.

Observation N°5 : Garantir la qualité des produits livrés est pour le fournisseur la seule façon d’entretenir une relation commerciale durable avec son client. La garantie de la qualité est à construire au même titre que le développement des fonctionnalités.

• Ne pas prendre au sérieux l’assurance qualité, ou ne s’en préoccuper qu’à la fin du développement, c’est mécaniquement se préparer à décevoir ses clients et les inciter à aller voir ailleurs, donc à perdre des parts de marché.

* Une vraie culture qualité produit n’a rien à voir avec l’obtention d’un quelconque label ISO, car le véritable objectif c’est le produit et l’équipe qui le développe, pas le label !

Laisser croire que livrer des progiciels, à des millions d’exemplaires, est une tâche facile comme on peut le lire entre les lignes de certains pamphlets anti-Microsoft, est un acte de désinformation dont le bénéficiaire ne sera certainement pas celui auquel on pense, LINUX, ou autres logiciels " libres " ! Le vrai problème, redoutable, est celui du taux d’erreurs résiduelles acceptable pour démarrer l’exploitation dans de bonnes conditions de service. A ce jour, seule la NASA a pu afficher des taux de l’ordre de 0,1 erreurs par millier d’instructions pour les logiciels de la navette spatiale, soit aux normes de l’édition, une seule erreur dans un volume de 200 pages ! La moyenne couramment observée est plutôt de 5 à 10 erreurs par millier d’instructions.

Observations N°6 : La capacité à intégrer de façon méthodique et réversible un ensemble de constituants, matériel et/ou logiciel, en un tout cohérent est une condition nécessaire mais non suffisante à la mise sur le marché de systèmes dont la qualité est véritablement garantie.

• Ignorer ou minimiser les difficultés de l’intégration, croire que tout finira par marcher sans avoir pris la précaution de vérifier tout ce qui doit l’être, ne pas ramener le risque à l’imprévisible, engendrera un coût de non qualité qu’il faudra cependant assumer. Il est particulièrement malvenu de le faire supporter par l’acheteur de technologie, ce qui s’est beaucoup pratiqué et se pratique encore beaucoup.

* L’intégration système est un vrai acte d’ingénierie, au sens fort du terme, qui se prépare dès la phase de conception !

Une statistique récente du Standish Group : Chaos, charter the seas of information technologies, nous apprend que seulement 16% des projets informatiques sont nominaux en termes de {coût, qualité, fonctionnalité et délai} ; 52% subissent retards et des baisses de qualité d’un facteur 2 à 3 ; 32% sont purement et simplement abandonnés ! C’est dire l’ampleur du problème de l’assurance qualité et de l’intégration, et des opportunités qui sont, de fait, offertes.

A l’aide de la chaîne de valeur, on peut commencer à analyser correctement les positions respectives et les forces technologico-économiques des Etats-Unis, de la France et/ou de l’Europe, du Japon. La grille d’analyse consiste à évaluer les forces et la dynamique à partir des produits, des standards du marché, des équipes.

Un premier constat s’impose :

• Qui tient les produits, tient le marché ; il oblige ses concurrents à rentrer dans sa propre logique et à en faire des suiveurs.

Au fur et à mesure que le temps passe et que les parts de marché se figent, la barrière d’entrée devient de plus en plus élevée pour devenir infranchissable comme dans les composants électroniques de type microprocesseurs.

Avec ce simple critère, les Etats-Unis sont les grands triomphateurs de l’affrontement qui s’est déroulé durant ces vingt dernières années. Leur victoire est totale. L’Europe n’a plus de constructeurs d’ordinateurs, les japonais ont été marginalisés. Les grands éditeurs de logiciels sont quasiment tous américains avec une seule exception notable, SAP, qui est allemande (mais créée à partir de la filiale IBM Deutschland). Les japonais sont inexistants. La France a perdu un de ses meilleurs atouts avec la CGI, et son produit phare PACBASE, rachetée par IBM et aujourd’hui entièrement fondue dans la structure IBM Global Services. CATIA doit une bonne part de son succès à un partenariat intelligent de Dassault et IBM fondé sur la connaissance du métier de la conception assisté et de la distribution de produits.

Reste le cas de Bull. Malgré toutes les critiques, souvent injustes, formulées à son encontre, Bull a été la seule société européenne à faire bonne figure dans la cour des grands. Les machines de la filière DPS7/GCOS7 ont eu un succès mondial dont NEC a dérivé sa gamme ACOS6. GCOS7 a été le seul système d'exploitation développé en Europe ces 25 dernières années et reste, à ce jour, le plus grand logiciel développé dans notre pays. Bull a su faire fonctionner un vrai bureau d'études de 4 à 5.000 ingénieurs capables de concevoir et de livrer des systèmes selon les standards qualité du marché. La conséquence de la disparition de Bull, en tant qu'acteur industriel, va être véritablement dramatique à moyen - long terme.

Bull, et plus anciennement CII, ont largement contribué à la naissance et au développement d'un tissu d'informaticiens de très haut niveau qui ont essaimé dans de très nombreuses entreprises, les créant parfois, en y apportant un savoir-faire système de première main qu'ils ne pouvaient acquérir ni dans les Grandes Écoles, ni à l'Université.

Cette source est désormais tarie, mais l'assèchement du terrain qu'elle irriguait ne se fera véritablement sentir que dans une dizaine d'années. Compte tenu des temps de latence, il sera alors beaucoup plus difficile de réagir.

Un deuxième constat, conséquence du premier, concerne les standards :

• Tous les standards importants dans le monde du logiciel sont aujourd’hui américains ; ils constituent une barrière de compétitivité incontestablement à l’avantage de l’industrie américaine.

Tous les langages de programmation sont américains. On ne fabrique plus de compilateurs en France, ni d’ailleurs en Europe. Les bases de données sont programmées en SQL, une invention des laboratoires d’IBM qui a fait le succès d’ORACLE. La seule société européenne qui fabrique encore des SGBD est allemande : Software AG. En matière de réseau, Ethernet et TCP/IP ont balayé le modèle à 7 couches de l’ISO. Les interfaces graphiques sont toutes construites sur une base X-Windows qui fut le résultat d’un transfert de recherche issu du projet ATHENA conduit par le MIT avec des financements IBM et DEC dans les années 80s. Microsoft, avec Windows, est en position hyper-dominante. Quant à Internet, c’est un phénomène américain, issu d’un projet de la DARPA des années 70s, où nous ne faisons que suivre. Globalement, c’est un désastre industriel de première grandeur pour l’Europe qui a dilapidé des milliards avec les programmes ESPRIT de la CE dans des aventures sans lendemain, dont l’échec était malheureusement prévisible pour cause d’oubli pur et simple du marché et des besoins réels des utilisateurs.

En matière d’ingénierie de systèmes d’information, MERISE qui fut un grand succès, s’est laissé déborder par la vague de l’objet et va probablement disparaître derrière UML. EUROMETHOD, sous pilotage de la commission européenne est, pour le moment, une aventure sans lendemain, très mal relayée par les structures nationales, et quasiment inconnue de ses utilisateurs potentiels. Les ateliers de génie logiciel (i.e. AGL) sont quasiment tous américains avec une exception notable MEGA ; la SEMA, société franco-britannique, a renoncé l’année dernière à développer l’atelier CONCERTO dont la R&D initiale venait du CNET. VERILOG, qui eut son heure de gloire dans les années 80s, est désormais sous contrôle de TELELOGIC qui est suédoise.

A propos des normes et standards on peut noter une différence radicale entre la pratique américaine et la pratique européenne, en particulier française. Aux Etats-Unis, c’est le marché qui impose une norme, ce n’est pas la bureaucratie. COBOL s’est imposé contre IBM et le PL1 grâce au comité CODASYL piloté par les utilisateurs ; le langage Ada, invention française, a échoué malgré le soutien des bureaucrates et des milliards de $ du DOD. UNIX a engendré le langage C sans l’aide d’aucun comité. Le pire est constitué par les normes complètement technocratiques et déconnectées du marché qui prétendent cependant légiférer le marché ; le plus bel exemple de ce type d’action vaine fut la norme PCTE qui était sensée structurer le marché des ateliers de génie logiciel : on connaît le résultat !

Il est dérisoire de vouloir créer de façon technocratique ses propres normes, mais c’est un défaut bien français. Notre intérêt est évidemment de jouer l’ouverture, les systèmes ouverts, voire même les logiciels " libres " au moins pour un temps, mais pas de façon naïve. Il est étrange de partir en croisade contre Microsoft sous l’étendard des logiciels libres qui sont tous américains ! Car comme dit P. Strassmann avec son bon sens coutumier " there is no zero cost for something of value ". Quand les appâts du logiciel " libre " auront été suffisamment mordus, il y aura bien un pêcheur pour relever les filets, et il ne sera probablement pas français ! C’est ce qu’a très bien compris ORACLE qui offre une version de son produit " packagé " avec LINUX.

De ce bilan peu glorieux pour la France et l’Europe, peut-on conclure que la partie est durablement perdue, et que tout doive être abandonné pour le seul profit des Etats-Unis ?

Non ! car c’est oublier une singularité de cette technologie de l’immatériel qui est d’être totalement tributaire du niveau de compétence de ses concepteurs/programmeurs, et donc du niveau de formation de ses ingénieurs.

Sous cet angle, l’Europe en général, et la France en particulier, ont un standard d’éducation et une culture d’ingénieur de tout premier plan, probablement le meilleur du monde. Nous sommes rompus à la pratique des abstractions et au maniement des concepts plus que dans tout autre pays, doublé d’un sens esthétique qui est le fruit de notre longue histoire, or ce sont des qualités indispensables à la création de bons logiciels.

Les grands mainframes et les systèmes d’exploitation propriétaires sont aujourd’hui banalisés par UNIX, les PC, Windows, etc. La situation qui s’ouvre à nous est totalement nouvelle et riche d’opportunités à saisir.

Ce qui nous fait le plus défaut ce sont la culture entrepreneuriale, le peu de goût du risque car la prise de risque n’est pas valorisée, une attitude protectionniste et frileuse derrière des standards artificiels dont le seul résultat est de nous mettre définitivement en retard, sans parler de la difficulté à mobiliser des capitaux, mais cela peut s’arranger plus vite qu’on ne pense quand on voit le dynamisme impressionnant, quoique tardif, des start-up françaises. Le plus grand danger qui nous guette, consiste tout simplement à se faire " siphonner " les bons ingénieurs et/ou les bonnes équipes comme on en a vu récemment plusieurs exemples. Le rachat de sociétés comme CHORUS Systèmes (spécialisé en noyau de système d’exploitation, on dit micro-kernel dans le jargon,) et O2 Technology (spécialisé en bases de données objet) est tout à fait illustratif de cette approche, malheureusement à notre détriment, et ce d’autant plus que ces sociétés avaient largement bénéficié de fonds publics ou parapublics.

Plus pernicieuse est la création par certaines sociétés d’instituts de formation qui délivrent des " proficiency " sur telle ou telle technologie, ce qui est le meilleur moyen de créer une sous-culture technique relativement docile qui ne connaîtra de la technologie que la partie purement utilisatrice, et évidemment pas la partie créative où sont les vrais savoir-faire qui resteront aux Etats-Unis, quand bien même l’institut en question dispose d’un centre de " recherche " européen.

Un troisième et dernier constat pourrait être celui du management de l’innovation. Nous ne sommes qu’au début des technologies de l’information et il y aura encore de nombreuses opportunités pour autant que l’on sache s’adosser sur nos vraies forces créatives, mais il faut une grande lucidité pour ne pas céder à la facilité des modes. A propos de l’innovation, on pourrait paraphraser la parole de G.Clémenceau qui disait que " la guerre est une affaire trop sérieuse pour être confiée à des généraux ". Il n’est pas évident que les chercheurs informaticiens soient les meilleurs stratèges industriels, car dans ce domaine à hauts risques il vaut mieux éviter d’être à la fois juge et partie. La réciproque est également vraie, car chacun opère sur des segments différents de la chaîne de valeur.

L'industrie et la recherche informatique sont fortement sujettes aux modes. Les exemples abondent. N'a-t-on pas vu, il n'y a pas si longtemps, un premier ministre prendre partie pour l'architecture RISC lors de négociations, d'ailleurs avortées, entre Bull et Hewlett-Packard, alors que les deux microprocesseurs les plus répandus étaient de bon vieux processeurs CISC commercialisé par Intel et Motorola. Distinction par ailleurs totalement artificielle avec l’augmentation du nombre de transistors par puce, alors que dans le même temps Bull fermait sa division compilateurs dont la maîtrise est cependant indispensable à l’exploitation de la puissance des microprocesseurs modernes.

De même, et en réponse au magistral coup de bluff des japonais avec les ordinateurs de 5^ème génération, beaucoup d'argent fut déversé sur le domaine de l'intelligence artificielle, alors que dans le même temps on taillait des coupes sombres dans les SGBD, ou les logiciels graphiques pour stations de travail qui furent, mais 10 ans plus tard, les moteurs de la formidable croissance de sociétés comme Microsoft, ou Oracle.

La filière supercalculateur a également bénéficié des largesses des crédits de recherche alors que le marché était inexistant et déjà saturé par CDC et Cray Research, mais rien pour développer PC, Stations de travail, Routeurs de communications, ou les " clusters " de machines multiprocesseurs, … si l'on excepte toutefois la lamentable aventure industrielle du plan informatique pour tous et des ordinateurs T06 - T07 aujourd'hui tous au pilon.

Là encore, pour que l'effort financier initial se concrétise, il faut un tissu industriel apte à le faire fructifier, et de toute façon un marché est toujours indispensable comme le montre le schéma de M.Porter rappelé ci-dessus. Que l'un ou l'autre fasse défaut, alors l'espérance de gain du transfert devient quasi nulle.

La " révolution " n'existe que dans la tête de ceux qui ne connaissent pas les règles du jeu industriel. Tous les grands succès informatique, sans la moindre exception, ont eu de longues, voire très longues, périodes de gestation. Le succès résulte toujours d'efforts soutenus pendant de nombreuses années. Le mythe des garages de la Silicon Valley fut une absurdité comique lorsque l'on sait que les dit " garages " étaient adossés à Stanford, Berkeley, … et à de nombreux centres de recherches d'une extraordinaire vitalité, sans parler des moyens de financements privés et du capital risque, essentiels au développement du tissu industriel. UNIX est totalement incompréhensible sans la connaissance de son père putatif MULTICS développé par le MIT, General Electric et Honeywell.

Les variations brusques sont généralement fatales à toute entreprise industrielle. Beaucoup de nos initiatives récentes, par ailleurs avec de très bonnes intentions, ont échoué à cause d'une méconnaissance absolue de ce qu'est véritablement une logique industrielle, et de ce qui rend les entreprises véritablement compétitives.

Pour faire une bonne recherche informatique, il est prudent de mettre le domaine à l'abri des modes et surtout diversifier les axes de recherche, afin d’éviter les effets de chapelle et le dogmatisme. Les modes jouent un rôle néfaste sur la sociologie et le financement de la recherche. Les hommes et les organisations étant ce qu'ils sont, si il y a de l'argent, on trouvera toujours quelqu'un pour expliquer de façon convaincante que telle ou telle action est vitale pour le pays.

Quoiqu'on fasse à la périphérie, les piliers centraux que sont l'algorithmique, les données, les communications, resteront au cœur des NTI, sans pour autant négliger la recherche technologique, l'architecture système logiciel et l’étude des procédés de fabrication du logiciel qui ne peut se faire qu’avec les industriels du domaine. Faute de quoi, on bâtit sur du sable !

A défaut de créer des produits, ce qui n’est vraiment pas son rôle, on peut attendre de la structure de recherche qu’elle contribue à créer des équipes, car derrière un produit ou un système qui connaît le succès il y a toujours une équipe pluridisciplinaire qui a su appréhender toutes les facettes de la problématique produit (cf. le cas de la société Business Object, exemplaire à tout égard, crée par essaimage d’une petite équipe d’Oracle France).

D’où un dernier constat :

• Pour qui sait construire des équipes créatives et pluridisciplinaires indispensables au développement de systèmes complexes, il y a une chance et des opportunités permanentes de revenir dans la compétition.

Mais là encore, il faut être particulièrement lucide, et tenir compte des délais quasiment incompressibles nécessaires à une bonne maturité des idées, des organisations et des hommes.

Voici, à titre d’exemple, un tableau comparatif de montée en puissance de différents types d’équipes de développement dont il faut bien comprendre que tout se joue lors de la création, en particulier grâce aux chefs de projets et aux architectes.

Avec cet angle de vue, on peut comprendre : a) pourquoi nos chances restent excellentes et b) où il est payant de mobiliser nos efforts, avant qu’il ne soit définitivement trop tard. La France dispose d’un très grand savoir-faire en matière de systèmes, et ses ingénieurs ont la bonne tournure d’esprit. C’est une ironie de l’histoire de savoir que la cybernétique qui est vraiment le fondement de l’ordinateur à connu chez nous un grand succès, dès les années 50. L’ouvrage fondateur de N.Wiener, CYBERNETICS or Control and Communication in the animal and the machine, avait d’ailleurs été édité conjointement par les MIT Press à Cambridge, et par Hermann à Paris dans la collection Actualités scientifiques et industrielles ! L’influence de ce courant de pensée à laissé une trace profonde dans des méthodologies comme MERISE ; il est d’ailleurs en train de réapparaître avec le Business Process Reengineering, aux Etats-Unis.

Les succès des équipes françaises en matière de grands systèmes sont incontestables et ce dans de nombreux domaines comme l’automobile, l’énergie, l’aéronautique, le spatial, les télécommunications, la défense, etc.

Ce qui fut, en son temps, la prérogative de Bull et de la défunte CII en matière d’ordinateurs, peut à nouveau se développer dans le sillage de ces secteurs où nous excellons, car ils seront, ou sont déjà tous fortement, voire même totalement dépendants des technologies de l’information. C’est d’ailleurs une carte que joue clairement un pays comme l’Inde qui met sur pied une véritable " Software Factory " avec garantie de qualité. Les coûts humains étant l’essentiel en matière d’ingénierie logiciel, la menace est très claire.

Nous sommes a une croisée de chemins. Ou bien on se ressaisit en capitalisant sur nos acquis industriels, encore nombreux, qui ont une réelle valeur marchande, ou bien on laisse aller. Dans cette dernière hypothèse, seule ne subsistera qu'une industrie d'intégration et de services dont le ciment et la vraie richesse, les progiciels, auront été fabriqués ailleurs, c'est à dire aux États-Unis, éventuellement par des français expatriés, ou en Inde. Il est recommandé de capitaliser sur ce qui a toujours fait notre force : la logique et la rigueur, une grande créativité qu'il faut canaliser par la prise en compte des indispensables règles de l'ingénierie et une vraie culture qualité fondée sur le produit.

Il est urgent de réfléchir, en toute lucidité, à ce que sera l'informatique de demain. Le renouvellement rapide du marché, les nouveaux besoins, ouvrent des opportunités où nos chances restent intactes :

• Une industrie de niches à haute valeur ajoutée, dans le sillage de nos grands pôles industriels (aéronautique, espace, télécommunications, nucléaire, transport, défense, etc.),
• Une industrie généraliste autour des marchés de masse que sont la microinformatique, les réseaux et bien sur Internet.

Les applications autours des réseaux (administration, sécurité,…), des données (data mining et/ou datawarehouse), du travail coopératif à distance (Intranet et Internet), les logiciels qui assurent l’interopérabilité des applications, la maîtrise architecturale et l'ingénierie des systèmes complexes sont d'immenses domaines où rien n'est encore joué mais où le temps est compté.

Aux Etats-Unis, le " President’s information technology advisory committee " en a fait une priorité nationale. Dans le rapport publié par ce comité, on peut lire : " We have become dangerously dependent on large software systems whose behaviour is not well understood. Therefore, increases in research on software should be given the highest priority. ". On attend désespérément une réponse de l’Europe, mais à défaut il faut noter les initiatives locales réconfortantes comme celle de la région Rhône-Alpes et du pôle grenoblois avec la création d’un centre spécialisé dans le logiciel pour l’industrie et les télécommunications qui s’intégrera dans une structure de quatre CNRT (centre national de recherche technologique). Il faut également signaler au niveau national la création de réseaux recherche« industrie comme le RNRT, et plus récemment le RNTL. Le risque pour de telles structures est d’oublier que l’informatique est par essence un phénomène mondial qu’il est impératif de penser comme tel. On peut raisonnablement espérer que dans le sillage de nos plus grands groupes, eux mêmes mondialisés, ce type d’erreurs sera évité, mais encore faut-il que l’informatique, et surtout le logiciel, soit correctement perçu par les grands décideurs. L’enjeu véritable, à l’échelle mondiale, est la création d’une vraie industrie des systèmes aujourd’hui largement dépendante des logiciels comme nous le rappelle le rapport ci-dessus, où la France pourrait jouer un rôle majeur.

L'effort de recherche, comme celui de nos formations supérieures, doit être recentré en tenant compte de cette nouvelle donne. Une large place doit être faite à l'ingénierie et à la recherche technologique en s'appuyant sur l'énorme potentiel humains des Grandes Écoles insuffisamment exploité, et ce dans un contexte résolument mondial. Des pans entiers de savoir-faire restent désespérément en jachères, faute d'enseignants formés à la logique et aux savoir-faire industriels. Cette défaillance qui n'est pas récente, n'est plus compensée par ce que des sociétés comme Bull dispensaient massivement en formations complémentaires à leurs ingénieurs.

Les projets de recherche et développement devraient être systématiquement organisés de façon à dégager des masses critiques de compétence et de savoir-faire sans lesquelles aucune action efficace et durable n'est possible, car seules susceptibles d’engendrer des retombées réutilisables par notre industrie des systèmes. On aura compris qu’il est indispensable que tous les maillons de la chaîne : formation, recherche, industrie, édition, maintenance soient présents pour espérer un retour sur investissement ce qui nécessite d'encourager l'essaimage de compétences dans les deux sens : recherche vers industrie, et industrie vers recherche, en évitant le gâchis humain de mise à la retraite anticipée de vrais professionnels qui n’ont pas eu le temps de transmettre leur savoir-faire aux nouvelles générations.