Association Française des
Sciences et Technologies de l'Information
Sommaire : Trois questions à Jean-Pierre Meinadier| L'actualité de la semaine | Théories et concepts | La recherche en pratique | Enseignement | Entreprises | Manifestations | Le livre de la semaine | Détente
 |
 |
 |
 |
"L'intégration de systèmes est un métier, quelque chose qui se fait, pas un thème abstrait de recherche au sens universitaire. On peut cependant en formaliser les concepts, et apprendre aux étudiants comment s'intégrer dans les projets où ils seront appelés à travailler."
Asti-Hebdo
: Votre livre "Le métier d'intégration de systèmes"
vient de paraître chez Hermès-Lavoisier. Quel en est le message,
par rapport à "Ingénierie et intégration des systèmes",
paru en 1998 ?
Jean-Pierre Meinadier : Initialement, je ne voulais faire qu'un seul livre. Mais le volume de mon texte, m' a conduit à le publier en deux livraisons. Le premier livre est un panorama des processus techniques d'ingénierie et d'intégration des systèmes avec les méthodes, techniques et outils qui correspondent. Le second rappelle (en annexes) les concepts d'ingénierie, les approches de modélisation et d'interopérabilité des systèmes, sous une forme brève et synthétique (actualisée pour tenir compte de quatre ans supplémentaires de réflexion). Mais son objet principal est de traiter, selon une vision système, de l'ensemble des processus du métier et des concepts et savoir-faire qui les sous-tendent : processus techniques, de management du projet, contractuels, d'organisation inter projets.
Le premier tome était une sorte de kaléidoscope des techniques, le second est une synthèse, certes fondée sur les approches "processus" récemment normalisées, par exemple par la norme ISO 15288 d'ingénierie système, mais surtout fruit de mes réflexions pédagogiques et de mon expérience industrielle. Je me suis permis, non sans hésitations, quelques réflexions sur le management des entreprises spécialisées dans l'intégration de systèmes, qui me sont à l'évidence plus personnelles.
Cela fait quarante ans que j'intègre des systèmes. J'ai commencé en 1962, au CEA en y créant les activités temps réel. On parlait alors des systèmes à base de petits calculateurs (par opposition aux grandes machines, à vocation scientifique). Il s'agissait du pilotage des expériences de physique et du monitoring des réacteurs et accélérateurs, activité typiquement industrielle. Avec mon équipe d'électroniciens et de programmeurs (le mot informaticien n'existait pas encore), nous avons acheté un grand nombre de calculateurs électroniques variées, avec des technologies exotiques comme les mémoire à magnétostriction... Le problème principal était de comprendre comment elles fonctionnaient pour pouvoir les connecter à l'environnement et les utiliser en tenant les échéances temps réel. Et le seul moyen que j'aie trouvé, c'est d'obtenir des équipes de maintenance qu'elles m'ouvrent leurs grands manuels et de suivre les fils... C'est à partir de ces connaissances que j'ai écrit mon premier livre, Structure et fonctionnement des ordinateurs (Larousse, 1ere édition 1971), qui s'est vendu en 80 /000 exemplaires à deux générations d'informaticiens. J'ai fait ainsi mes premiers pas en ingénierie de systèmes, tantôt en maître d'œuvre pour les systèmes de pilotage d'expériences, tantôt en assistant du maître d'ouvrage pour les systèmes industriels lourds comme le monitoring des réacteurs expérimentaux.
Toujours dans le groupe CEA, on m'a ensuite confié la création et la direction générale de Gixi, filiale d'intégration de systèmes de Cisi. J'étais, si l'on peut dire, un "manager à caractéristique technologique forte". Comme nous travaillions presque exclusivement sur des projets au forfait allant de systèmes de robotique avancée à de grands systèmes de gestion, j'ai dû m'intéresser de près à la préparation des devis et à la manière de les tenir. Cette activité coûte cher en elle-même (j'ai souvenir d'un proposition qui nous a coûté 700 000 F de l'époque, pour un projet que nous avons facturé autour de 30 millions). Elle consommait de 3 à 5% de notre chiffre d'affaires. Et il faut qu'elle soit fiable, sinon l'on ne tient pas ses engagements ni ses budgets. J'ai constaté aussi que la moitié du temps passé, entre le moment où l'on signe le contrat et celui où le système est mis en recette, intégré dans son environnement, après formation des administrateurs, des utilisateurs et des mainteneurs... la moitié de ce temps est consacré à ce qu'on appelait alors la spécification ("la spec", pour les initiés), et qu'on appelle aujourd'hui l'ingénierie des exigences voire, plus précisément, la création des exigences système. Dès cette époque, d'ailleurs, nous avons commencé à structurer les spécifications, à en numéroter les items, à définir les méthodes de prévision (modélisation quantitative) et de mesures des exigences de performance (simulateurs de charges des systèmes)... et donc à nous rapprocher de ce qu'est défini comme une exigence aujourd'hui.
Une douzaine d'années plus tard, la société a été démantelée lors d'une restructuration du groupe. Après quelques années de conseil (activité que je continue, il ne faut pas perdre la main), j'ai eu la chance d'être élu sur la chaire d'intégration de systèmes que le Cnam venait de créer. J'ai alors eu dix années pour créer des enseignements correspondants et approfondir mes réflexions sur le métier. Cet ouvrage en est le résultat.
Asti-Hebdo : Pour quelqu'un qui a une telle expérience industrielle, votre livre paraît pourtant des plus abstraits. On s'attendrait plutôt à vous voir employer les techniques du récit, chères aux "communautés de pratique". Votre approche convient-elle à vos étudiants ?
J.-P.M. : Ce n'est quand même pas mathématisé, sauf quand nécessaire ! Mais l'ingénierie de systèmes implique un fort niveau d'abstraction, et ce ne sont pas uniquement des récits qui permettent d'y accéder. Et il est vrai que j'émaille mes cours d'anecdotes et d'études de cas, que mes étudiants apprécient. Mais, dans mes livres, j'ai cherché à formaliser le métier en illustrant le texte par de nombreux graphiques modélisant concepts et processus du projet (le système pour faire) avec les mêmes techniques que les modélisations utilisées pour spécifier et architecturer le système à faire (tout en me référant à de nombreux exemples dans des secteurs d'application différenciés.
Dans mon expérience du métier d'intégration de systèmes complexes, j'ai toujours vu opérer trois types de profils.
Il y a d'abord les techniciens. Des gens qui connaissent parfaitement leur métier. Mieux que les ingénieurs. Mais ils ne savent pas en sortir. Dès qu'arrive une technologie vraiment nouvelle, ils décrochent. Je l'ai vu, par exemple, avec les premiers ordinateurs qui disposaient d'un système d'exploitation, contrairement aux premières machines où il fallait tout écrire en langage machine, y compris les routines de gestion entrées/sorties et des interruptions. Ils ne se sont remis à l'œuvre qu'après avoir compris en détail comment fonctionnaient le système d'exploitation. Heureusement à l'époque il s'agissait d'exécutifs relativement simples !
Au deuxième niveau, les ingénieurs. Ils connaissent moins bien que les techniciens le détail de chaque technique. Par contre, ils sont capables d'en manipuler plusieurs, un peu comme des objets. Ils savent ce qu'on peut en faire. Et, quand quelque chose ne va pas, ils sont capables d'aller au fond des choses et de trouver le point important qu'il faut résoudre, ou encore de discuter efficacement avec des experts du domaine.
L'ingénieur de système complexe, enfin, a un
niveau d'abstraction lui permettant de travailler encore plus en largeur.
Il manipule un nombre encore plus élevé de disciplines et de techniques,
et surtout il a une grande capacité de
maîtrise des interactions, qui deviennent fondamentales à ce niveau,
ceci dans une approche globale de pertinence et
d'optimisation.
Mes cours répondent à ces différents niveaux. Les techniques informatiques d'abord : je serais encore capable de faire un cours sur l'architecture des ordinateurs (je l'ai fait de 1972 à 1999 à l'Ecole centrale !) et j'ai crée au Cnam un cours très "techniques informatiques" d'intégration de systèmes client serveur qui a du évoluer chaque année en suivant les technologies .
Au deuxième niveau, il y a ce que j'enseigne au titre propre de l'intégration de système au Cnam et qui s'adresse aux filières d'ingénieur en fin d'études ou aux mastères spécialisés, sous forme d'exposés de synthèse et de travaux en commun enseignants auditeurs. J'essaie, alors qu'ils sont destinés à prendre des responsabilités de projets dans l'entreprise, de faire réfléchir les auditeurs aux invariants fondamentaux des approches système (systèmes technologiques, systèmes d'organisation et systèmes d'information), à la manière de les mettre en pratique de manière pertinente et optimisée et de se comporter ainsi en ingénieurs aptes à maîtriser des problèmes un certain niveau de complexité et à concevoir des solutions prenant en compte toutes les contraintes du problème. et ainsi... de ne pas "se planter" dans les environnements industriels où ils vont appliquer leurs compétences.
Enfin, au troisième niveau , ce qui correspond le plus au contenu de mes derniers ouvrages, j'enseigne, dans le contexte de l'institut (Centre d'études pour la maîtrise des systèmes et du logiciel, CMSL) que nous avons crée avec le titulaire de la chaire de génie logiciel, à des ingénieurs de système déjà en fonction soit en cours interentrprise, soit en stages « intra » dans de grandes entreprises ou institutions comme Alcatel-Espace ou la Délégation générale à l'armement.
C'est un domaine où il y a toujours à apprendre, d'autant qu'il n'est pas formalisé. On commence à pouvoir s'appuyer sur tout un jeu de normes, élaborées initialement sous la pression de grands organismes comme le DOD (le ministère de la Défense américain) et d'industriels . Ces normes sont d'ailleurs trop peu connues. Combien de développeurs informatiques connaissent l'ISO 12207, qui est pourtant la norme de base du génie logiciel. Mais, entre les normes qui formalisent les activités à mener et le véritable savoir-faire, il y a les méthodes (souvent spécifiques à un logiciel déterminé ou d'un certain type). Et derrière les méthodes se cache la théorie des systèmes.
Je sais bien que les informaticiens purs et durs (et beaucoup d'ingénieurs) ont une image négative de la « systémique » approche qu'ils considèrent comme peu scientifique Pour moi, le premier des systémiciens s'appelait Descartes, même s'il n'avait pas encore compris toute l'importance des interactions : l'approche analytique à impacté toutes nos disciplines scientifiques. L'approche systémique les relient et les intègrent. Des auteurs comme Walliser ou Forrester ont apporté à la systémique une vision de scientifique et d'ingénieur. Jean-Louis Le Moigne a fait une synthèse convaincante des deux aspects. Il nous a amenés à réfléchir. Et finalement, si vous regardez l'ensemble des approches méthodologiques et de modélisation des différents types de systèmes, on la retrouve toujours en arrière-plan.
La théorie des systèmes sous-tend ainsi toutes les méthodes et reste le dernier recours quand aucune méthodes ne marche. La spécification implique une approche systémique de l'ensemble du problème selon de multiples points de vue, la complexité du problème à résoudre implique une approche analytique de décomposition en sous-problèmes (tout en analysant leurs interactions de peur de mutiler le problème), jusqu'à l'obtention de sous-problèmes suffisamment simples pour leur apporter des solutions, ce qui implique alors un problème d'intégration optimum de ces éléments de solution aptes à conférer au système résultant les comportements et aptitudes spécifiés ; les quatre premier chapitres de mon livre synthétisent ces concepts appliqués tant au système à faire qu'au projet pour le faire. La théorie des systèmes est à la base de la culture de l'ingénierie des systèmes.
Asti-Hebdo : Ne peut-on alors qualifier votre travail de "recherche" à proprement parler ?
J.-P.M. : Si on pense à la recherche universitaire, je répondrai non. L'ingénierie et l'intégration de systèmes complexes, ce n'est pas de la recherche. C'est plus une accumulation de savoir-faire et d'expériences industrielles dont on cherche à formaliser les invariants et les bonnes pratiques qui ont réussi. C'est un métier que l'on fait. L'équipe qui réussit à concevoir un système aussi complexe qu'un système de télécommunication par satellites, depuis l'élaboration des concepts d'emploi jusqu'à la destruction ou la désorbitation des satellites, voilà vraiment un intégrateur de systèmes. Et cette activité, ce sont par nature les industriels qui la maîtrisent, pas les universitaires.
Dans la société que je dirigeais, nous ne faisions pas de recherche au sens strict. Nous allions voir ce que faisaient les chercheurs (par exemple à l'Inria), et regardions si nous pouvions les appliquer dans nos systèmes ou nos produits. Bref, notre R & D s'apparentait à de l'innovation. C'est autre chose ! Notre rôle était de relier les concepts que les chercheurs faisaient émerger au niveau de leur recherche et d'évaluer l'apport de leur industrialisation et de leur mise en œuvre dans l'ingénierie de systèmes pour répondre efficacement aux besoins de la société technique et économique. Nos systèmes étaient très souvent des moutons à cinq pattes intégrant ainsi plusieurs innovations (d'où mes anxiétés lors des signatures de proposition !).
Mais si les universitaires ne font pas d'intégration de systèmes, en revanche, ils développent des techniques de preuve formelle des systèmes, ils élaborent des techniques de validation, de sûreté de fonctionnement, et même de transformation automatique des exigences, ou encore des techniques d'interopérabilité... En focalisant sur des points précis, ils construisent d'indispensables fondements pour l'ingénierie et l'intégration de systèmes complexes. A l'inverse, les intégrateurs utilisent et assemblent les résultats de ces recherches dans des méthodes et outils cohérents et efficaces pour supporter leur métier..
C'est une des particularité du Cnam de mixer des professeurs issus de l'université avec leur expérience de chercheur et d'autres issus de l'industrie. C'est une rencontre de deux mondes, quelquefois conflictuelle, mais plus souvent fructueuse. Même si mon livre peut sembler abstrait. S'il cherche à formaliser, il n'a pas la prétention d'être le résultat d'un travail de recherche au sens des critères de la recherche universitaire. Mon métier, ce fut d'intégrer des systèmes dans l'industrie. Mon livre, qui traite de ce métier, est plutôt une vision de sysnthèse intégrant de multiples travaux venant de la recherche mais aussi des savoir-faire peu à peu formalisés par l'industrie, par des associations d'industriels tels que l'Association française d'ingénierie système (Afis) et des instituts de normalisation.
Au-delà des cours d'informatique que j'ai continué à dispenser, les cours d'intégration des systèmes sont souvent vus par mes auditeurs comme de l'intégration des enseignements. Par nécessité, nous enseignons par discipline : (la recherche universitaire est d'ailleurs organisée par discipline ce qui peut quelquefois apparaître comme un frein à l'émergence de nouvelles disciplines et à la transversalité). Intégrer des systèmes c'est aussi intégrer de nombreuses disciplines, le processus « d'intégration des disciplines » est un des processus de base de l'ingénierie systèmes : saurait-on concevoir et intégrer un système de télécommunication spatiale en n'en voyant que la mécanique ou que l'orbitographie ou que l'énergétique ou que la télécom ou que la mise à poste ? ou simplement faire évoluer le système d'information d'une entreprise en ne connaissant que les processus métier du contrôle de gestion ou que la conception des protocoles de communication ?
Ce qu'un tel enseignement peut donner, en dehors des travaux pratiques et du faire-faire, c'est la capacité de raisonner correctement sur les concepts fondamentaux du domaine de l'ingénierie et l'intégration, de les structurer, de savoir les mettre en œuvre en intégrant les différentes disciplines de l'ingénieur. Et là, effectivement, je m'appuie sur une multitude d'exemples concrets. Au point que mes élèves qui ont une expérience industrielle me disent : "Vous ne nous faites pas un cours, vous traitez des problèmes que nous vivons tous les jours". Et ceux de formation première qui reviennent de stage disent "Nous avons appliqué ce qu'on nous appris dans les dans les différents cours au sens classique (programmer en Java, par exemple). Mais nous n'aurions pas pu nous intégrer au milieu ou apprendre très vite les méthodes, langages ou outils choisis par l'entreprise sans votre cours. C'est vous qui nous avez permis d'utiliser et de mettre en oeuvre ce qu'on nous avait appris". Plus humblement j'espère les avoir aidé à structurer les connaissances qu'ils avaient acquises : d'intégrateur de système, serais-je devenu intégrateur des enseignements ?
En tout cas j'ai cherché dans ce livre à synthétiser ma double expérience industrielle et pédagogique du métier d'ingénierie et d'intégration de systèmes.
Propos recueillis par Pierre Berger
Le site de l'EPI http://www.epi.asso.fr vient de faire peau neuve pour plus de clarté et d’efficacité. On y trouve les textes fondateurs de l’association (créée en 1971) et les déclarations des assemblées générales successives ; une sélection d’articles pédagogiques concernant l’utilisation de l’ordinateur dans les différentes disciplines et également l’enseignement de l’informatique. (Rappelons que l’ensemble des articles et documents parus dans la revue de l’EPI de 1985 à 2001 sont disponibles sur le cédérom « 15 ans d’articles » présenté sur le site).
Une rubrique « historique » originale rassemble des documents, souvent peu connus, concernant l’histoire du déploiement de l’informatique pédagogique dans le système éducatif au cours des quarante dernières années. Cette rubrique – comme les autres – sera complétée au fil des mois.
Une rubrique « logiciels » présente les logiciels EPI, ceux de la bourse de diffusion dont environ 150 sont déjà librement téléchargeables, ainsi que des textes et informations sur les logiciels libres.
In moteur de cherche performant permet de fouiller dans le site et notamment dans les archives du magazine électronique EpiNet. Il est possible de s'abonner à un « alerteur » qui vous signale les nouveautés du site : epi_mag-suscribe@epi.asso.fr.
Communiqué par Jacques Baudé, président d'honneur de l'EPI
On trouvera un substantiel dossier de l'Adit, relatif au "spyware" (encore un xware...) sur le site de Futura-sciences (http://futura-sciences.com/decouvrir/d/dossier166-1.php ).
Le mensuel Progiciel Expert, du CXP, consacre à l'e-procurement un dossier dans son numéro de février 2003, intitulé "Les nouveaux habits de la gestion des achats", en dix points : les enjeux aujourd'hui, pourquoi recourir aux technologies Internet, que recouvrent les notions e-procurement et e-sourcing, où en sont les entreprises utilisatrices, quels sont les acteurs, quels bénéfices en attendre, combien coûte un projet, pourquoi les places de marché n'ont-elles pas connu le succès escompté, les freins à un tel projet, quelles sont les perspectives du marché.
Selon Le Parisien du 4 février 2002, on compte encore dix-huit millions de Français fidèles au 36.15. France-Télécom réalise encore 300 millions d'euros de bénéfices chaque année avec cet appareil. L'annuaire électonique vient en tête des utilisations (90% des appels), suivi des comptes bancaires et de la vente par correspondance. En revanche, les messageries roses sont en net déclin depuis l'arrivée d'Internet. On trouvera plus de précisions et une approche plus professionnelles dans Le Monde Informatique du 7 février.
Dans le numéro de février d'Expertises
(mensuel consacré au droit de l'informatique) trois articles à
signaler :
- une interview sur la sécurité des systèmes d'information
de Daniel Guinier, par Monique Linglet, à qui il explique surtout l'évolution
de sa carrière de chercheur et d'entrepreneur (société
0sia) ;
- une note sur le spamming "en quête de régulation",
par David Forest ; on pourrait aller vers une consécration législative
de l'opt-in
- un article détaillé de Julie Jacob sur les panoramas de
presse électronique : contrairement à la revue de presse
qui, sous certaines conditions, peut être réalisée sans
autorisation préalable des auteurs des oeuvres concernées, l'exploitation
de contenus informationnels pour réaliser des panoramas de presse en
ligne nécessite l'autorisation préalable des titulaires des droits.
L'auteur signale notamment le rôle du CFC
(Centre français d'exploitation du droit de copie).
Deux grands articles, soit en tout plus de vingt pages A4 sur UML et le temps réel dans le numéro 63 (décembre 2002), de la revue Génie Logiciel :
- Isabelle Perseil se demande "Est-il souhaitable d'intégrer davantage de formalisme pour pouvoir spécifier plus complètement les contraintes temps réel ou bien UML peut-il "déléguer" ce type de spécifications au langages formels, en gardant néammoins un contrôle global sur l'architecture du système via la nouvelle ingénierie MDA dont il est pour l'instant un support privilégié?
- Philippe Leblanc propose une introduction à UML2 et à l'outil Tau G2 pour le développement de systèmes réactifs.
Claire Rémy, dans Le Monde Informatique du 7 février, consacre presque deux pages entières au thème Maîtriser la complexité des logiciels. S'inspirant notamment des travaux de Jean-Claude Rault au CMSL (Cnam), l'article comporte des encadrés sur les outils et les méthodes de mesure de cette complexité.
Programmation en PHP, par Léon Atkinson. 658 pages et un CD-Rom. Un manuel de référence allant dans le détail des fonctions. Campus Press.
"Afin d'apporter aux établissements des repères et un soutien
dans la mise en oeuvre de la construction de l'espace européen "
de l'enseignement supérieur (LMD), l'Amue propose un espace en ligne
d'information et d'échanges. Il comporte un ensemble de rubriques qui
donne accès au contexte historique et réglementaire de la réforme
et à des informations concernant la mutualisation des pratiques dans
les établissements. Une liste de discussion permet à chacun de
confronter et d'enrichir ses approches locales, ainsi que de partager réflexions
et interrogations. Consulter le dossier : http://www.cpu.fr/Dossier/LMD
- Cycle "règles de l'interopérabilité"
:
26/02 - La deuxième version du cadre commun d'interopérabilité.
20/03 - La formation à distance et l'interopérabilité.
- Cycle "services en ligne et middle-office inter collectivités"
27/02 - Les solutions J2EE.
06/03 - L'état de l'art des services en ligne.
12/03 - Les solutions .NET.
26/03 - Les solutions Lamp.
02/04 - Les portails : l'intégration avec les systèmes d'information.
- Cycle "réutilisation des logiciels"
05/02 - La réutilisation des logiciels dans les adminsitrations.
27/02 - XML et open-source.
26/03 - Middle-office : Les solutions LAMP.
- Cycle "réutilisation des données, XML et Open source"
05/03 - L'intégration des flux documentaires.
- Cyble "gestion de la connaissance"
13/03 - Le groupware.
20/03 - La formation à distance et l'interopérabilité.
03/04 - Formation en ligne : plate-forme dédiée ou ASP ?
- Cycle "infrastructures de gestion de clés"
06/03 - Retour de réalisations d'IGC.
03/04 - Retour de réalisations d'IGC.
- Rencontres des maîtres d'ouvrage des services en ligne
28/02 - Chargés de mission pour les TIC auprès des SGARE.
27/03 - Personnels des régions.
02/04 - Personnels des départements.
09/04 - Personnels des communes.
17/04 - Entreprises ou mission d'assistance à la maîtrise d'ouvrage.
Contact : mailto:atica@atica.pm.gouv.fr
L'Aleure (http://diffusion.agence.cpu.fr/wws/info/aleure/) (Amicale des listes de l'enseignement universitaire et de la recherche) propose une coopération pour la diffusion de l'information. Voici la présentation qui figure sur son site :
Aleure réunit de façon informelle des responsables de listes de diffusion et d’information du monde de l’enseignement supérieur et de la recherche. Si vous n'êtes pas dans ce cas, vous pouvez vous abonner directement aux différentes listes mais pas à Aleure. En écrivant à aleure@ml.agence.cpu.fr vous pouvez proposer une information qui sera lue, et éventuellement signalée, par des listes qui touchent plusieurs milliers ou centaines de personnes travaillant dans un établissement ou intéressées par l’actualité universitaire. Les messages sont soumis à modération préalable, pour limiter la publicité abusive et s’assurer que les informations correspondent à l’esprit de l’amicale : sujet d’intérêt général concernant l’enseignement supérieur et la recherche. Les demandes d'informations sur les inscriptions ou les établissements sont à adresser directement aux établissements concernées.
Parmi les membres actuels d’Aleure (liste non exhaustive), figurent
des responsables des listes suivantes :
o Bulletin de l’Association Bernard Gregory (18300 abonnés)
o Bulletin de liaison de l'Université Paris-Sud (8000 abonnés)
o Chroniques de la Fondation A. Kastler (500 abonnés)
o Diffusion Paris 7 de l’Université Paris 7 - Denis Diderot (5500
abonnés)
o Framonde - Agence universitaire francophone (300 abonnés)
o InfoFl@sh : la Newsletter de l'Université de Savoie (la petite dernière
née en novembre 2002 !)
o Journal électronique de l’Université Louis Pasteur (2300
abonnés)
o Lettre d’information Act-U de la Maison des universités (3000
abonnés)
o Reperes du Bureau des études statistiques sur la recherche de la DPD
- Ministère de la jeunesse, de l'éducation nationale et de la
recherche (500 abonnés)
o Mél du Web SG - CNRS (3000 abonnés)
o Univ-Méditerranée.Infos de l'Université de la Méditerranée
(2500 abonnés)
o VeillExpress de l’Université du Québec (200 abonnés)
Et n'oubliez quand même pas de passer l'information à Asti-Hebdo (mailto:pmberger@noos.fr) !
- Afia
- Afig
- Afihm
- ASF - ACM Sigops
- Atala
- Atief
- Cigref
- Creis
- GRCE
- Gutenberg
- Inforsid
- Specif
Dans une certaine mesure, le travail de Jean-Pierre Meinadier, que nous interviewons dans ce numéro, peut être considéré comme un volet de la gestion de projets informatiques à la française.
C'est une autre vision que nous apporte l'ouvrage Gestion de projet informatitque en pratique, de Pankaj Jalote (Campus Press 2002. Original Software project management in practice, Addison-Wesley 2002). Et c'est, à notre connaissance, une première : les recommandations d'un directeur de la qualité indien, travaillant au service d'une des grandes firmes logicielles de ce pays, Infosys. On comprend l'importance, pour ce pays, de se donner l'image et la réalité d'une solide organisation au service de la qualité. Elle se concrétise, pour cette firme, par une certification CMM au niveau 5 (le plus élevé). Pour une grande part, l'ouvrage "Gestion de projet informatique en pratique" peut donc se lire comme une présentation de la méthodologie CMM (Capability maturity model). Après une introduction à cette méthode et à sa mise en oeuvre chez Infosys, le livre s'organise en deux grandes parties : planification du projet , réalisation/clôture. L'ensemble est détaillé, précis, pas toujours facile à lire, notamment du fait de sa métrologie envahissante. Mais on n'a rien sans rien !
Connue plutôt pour son (légendaire)
sérieux, la Compagnie a maintes fois montré qu'elle sait aussi
jouer de l'humour. Décernons un prix à sa publicité "Il
était une fois....". Les dirigeants d'une entreprise en difficulté
décidèrent d'acteur un AUB (adaptateur universel spécial
business). "D'après la notice, l'AUB pourvait connecter absolument
tout ce qu'on voulait. Il y avait un connecteur prou l'e-mail et un autre pour
le données, une prise pour les centres d'appel. Un port pour le imprimantes.
Des broches pour les équipements sans fil. Une fiche pour la chaîne
logistique.... Mais la réalité était bien différente...".
C'est alors (vous l'attendiez, bien sûr), que les dirigeants firent appel
à IBM.
Pour le plaisir des mots, Jean-Claude Zylberstein a publié (en 1996, mais nous venons de le découvrir) un savoureux "Dictionnaire des mots rares et précieux". Editions 10/18. Original Seghers 1965.