\documentclass[a4paper,11pt]{report}
\usepackage[T1]{fontenc}
\usepackage[latin1]{inputenc}
\usepackage[francais]{babel}
\usepackage{vmargin}
\setmarginsrb{2.2cm}{2.2cm}{2.2cm}{2.5cm}{0cm}{1cm}{0cm}{0cm}

\newcommand{\bit}{\begin{itemize}}
\newcommand{\eit}{\end{itemize}}

\title{La documentation logicielle}
\author{Yoann Guillot}

\begin{document}
\maketitle
\tableofcontents
\chapter*{Introduction}
\addcontentsline{toc}{chapter}{Introduction}
La documentation ou l'art de rendre visible les actions menées est l'un des
fondements de l'assurance de la qualité. Une documentation appropriée est
essentielle pour :
\bit
\item atteindre la qualité requise ;
\item évaluer les systèmes qualité ;
\item améliorer la qualité ;
\item mettre à jour les améliorations.
\eit

Pour maîtriser un projet, il est recommandé de définir et d'élaborer les
documents concernant le produit à développer, les actions à entreprendre avec le
planning associé, les ressources utilisées, et la façon de procéder.

Ces documents ne sont pas établis au hasard mais s'inscrivent dans la politique
qualité de l'entreprise.

\chapter{Les niveaux de la documentation}
On peut identifier trois niveaux de documentation du logiciel :
\bit
\item Le premier niveau concerne les lignes directrices de la politique de
l'entreprise ;
\item Le deuxième niveau décline la politique définie au premier niveau en
identifiant et détaillant les procédures génériques et leurs modalités
d'application dans l'entreprise ;
\item Le troisième niveau se rapporte à la documentation des projets et des
enregistrements relatifs à la qualité.
\eit

\section{Documentation liée à la politique de qualité de l'entreprise}
Quelle que soit la taille de l'entreprise, il convient de disposer d'un
référentiel qui décrit les dispositions prises par l'entreprise pour chacune des
rubriques de la norme ISO 9001 dans un cardre contractuel, ainsi que celles de
la norme ISO 9004 dans une vision de mise en {\oe}vre du management de la
qualité en interne. Une typologie de la documentation décrivant le système
qualité est :
\bit
\item Manuel qualité ;
\item Manuel assurance qualité ;
\item Plan de développement et plan d'assurance qualité.
\eit

\section{Documentation sur les procédures}
Le manuel qualité est généralement complété par des documents du système
qualité, tels que les procédures, instructions, modes opératoires.

Une procédure écrite comporte généralement l'objet et le domaine d'application
d'une activité :
\bit
\item Ce qui doit être fait, et qui doit le faire ;
\item quand, où et comment cela doit être fait ;
\item quels matériels, équipements et documents doivent être utilisés ;
\item comment cela doit être maîtrisé et enregistré.
\eit

\section{Documentation des projets informatiques}
Ce type de documentation est celui qui nous concerne le plus.

L'information des projets est une activité essentielle de description de l'objet
à réaliser et de pilotage du processus de réalisation.

Or, si cette information doit être structurée et organisée, elle n'est pas
forcément figée à un instant donné mais évolue et se précise tout au long de la
réalisation de l'étude, du développement et de l'exploitation de l'application.
Ainsi s'il est possible d'éditer sous forme documentaire l'état d'un système à
la fin d'une phase particulière, par exemple pour réceptionner cette phase,
l'édition du même document lors d'une phase ultérieure comportera les évolutions
introduites sur le système d'information concerné depuis la dernière édition.

Le système d'information d'un projet doit être construit pour produire un
ensemble de documents selon la classification suivante :
\bit
\item Documents de relation contractuelle ;
\item documents de gestion de projet (vision interne) ;
\item documents d'assurance de la qualité (vision externe dans une relation
contractuelle) ;
\item documents d'étude et de développement ;
\item documents d'utilisation et de soutien.
\eit

\subsection{Socuments de relation contractuelle}
Les documents dans une relation client-fournisseur, décrivent la nature de la
prestation et des résultats attendus, les obligations réciproques pendant et
après la réalisation, puis le constat de son bon achèvement.

Les documents pour les relations contractuelles sont les suivants :
\bit
\item Le cahier des charges ;
\item la proposition ;
\item la convention et ses annexes ;
\item les documents d'engagements complémentaires ;
\item les documents de réception.
\eit

Le canevas général est ccelui d'un client qui consulte un ou plusieurs
fournisseurs potentiels auxquels il décrit ce qu'il attend d'eux dans lun cahier
des charges. Ce peut être un cahier des cherges d'étude, de réalisation de
logiciel, ou de mise en {\oe}uvre d'un progiciel, etc.

Chaque fournisseur répond à la consultation en adressant au client une
proposition technique et financière assortie d'une description de la manière
dont il compte s'y prendre pour mener à bien l'ouvrage attendu, ce qui constitue
les prémices d'un plan de développement d'un plan d'assurance qualité.

La négociation qui suit sert à préciser ou à revoir divers éléments, ce qui
induit éventuellement un enrichissement du cahier des charges initial et de la
proposition jusqu'a ce qu'un accord intervienne.

La propositino formellement acceptée par le client est alors intégrée dans un
contrat.

Lorsque les parties le souhaitent, la proposition est encadrée par un
environnement juridique, ce qui conduit à une convention ayant valeur de contrat
dès lors qu'elle est formellement acceptée par le client et le fournisseur.

La proposition ou la convention peuvent prévoir que le cahier des charges, le
plan de développement et le plan d'assurance qualité soient l'un et/ou l'autre
finalités au cours de l'exécution du contrat.

Lorsque le contrat est un contrat d'étude, la fourniture qui en est attendue est
de nature à devenir à son tour le cahier des charges d'une autre consultation.

\subsection{Documents de gestion de projet}
Les documents de gestion de projet sont les outils du chef de projet pour la
planification détaillée du projet, le suivi permanent et régulier et le bilan
permettant de tirer les enseignements du projet.

Les documents de gestion de projet sont les suivants :
\bit
\item Plan de développement ;
\item documents de suivi de projet ;
\item documents de bilan.
\eit
Ces documents contiennent respectivement les supports de prévision, de suivi, de
contrôle et de bilan qui seront complétas tout au long de l'exécution du contrat
au titre de la gestion de projet par les éléments le précisant et par les
mesures ou les résultats produits au titre du suivi d'avancement du projet.

\subsection{Documents d'assurance de la qualité}
Les documents d'assurance de la qualité sont destinés à :
\bit
\item Aider les fournisseurs à définir et organiser les dispositions spécifiques
à mettre en {\oe}uvre pour s'assurer de la qualité d'une fourniture ;
\item aider les clients à acquérir la confiance du fournisseur quant à sa
maîtrise des opérations qui lui sont confiés.
\eit

Les documents de l'assurance de la qualité sont les suivants :
\bit
\item Plan d'assurance qualité ;
\item rapports d'audit interne ;
\item raports d'évaluation en fin de phase ;
\item plan de tests ;
\item documents de coordination.
\eit

Dans les cas de projets simples, les documents d'assurance de la qualité cités
ci-dessus peuvent ne pas s'avérer utiles dans la mesure où le plan de
développement suffit pour énoncer les dispositions pertinentes.

\subsection{Documents d'étude et de développement}
Les documents d'étude et de développement sont les suivants :
\bit
\item Les rapports de l'étude préalable ;
\item les rapports de l'étude détaillée ;
\item les rapports de dévelopement.
\eit

\subsection{Documents d'utilisation et de soutien}
Les documents d'utilisation et de soutien ont les finalités suivantes :
\bit
\item Donner une information générale aux différents partenaires ;
\item assurer la formation des utilisateurs ;
\item fournir une aide pour l'utilisation courante en apportant une synthèse et
une réponse aux cas particuliers.
\eit

\chapter{Les standards}
Il existe deux grands standards traitant de la documentation logicielle au sein
de la création d'un produit logiciel :

\section{DoD : Department of Defence}
La norme DoD 2168 a été produite par le département de la défense des
\'Etats-Unis. Elle est de fait un standard mondial. Son objectif est de
maîtriser la qualité du développement logiciel afin de permettre la
certification du logiciel. Elle possède des plans prédéfinis jusqu'au niveau de
granularité du paragraphe.

\section{GAM : Guerre Air Mer}
Le standard GAM T17 (v2) a été créé par l'armée française afin de maîtriser :
\bit
\item La complexité intrinsèque du produit logiciel ;
\item la complexité du développement lui-même ;
\item d'assurer la qualité sur les plans technique et organisationnel ;
\item de maîtriser les évolutions du logiciel.
\eit
Elle est surtout utilisée en France. Ce standard peut fonctionner selon deux
modes : à dévoppement indépendant, qui est surtout utilisé pour les gros
systèmes ; et à développement non indépendant, qui convient aux petits systèmes.
Le GAM offre un processus itératif.

\chapter{La documentation logicielle minimale}
Une documentation logicielle minimale est divisée en 5 dossiers :
\bit
\item Dossier de certification ;
\item dossier de validation ;
\item dossier d'intégration ;
\item dossier d'analyse ;
\item dossier de programmation.
\eit

\section{Dossier de certification}
Ce dossier doit comporter :
\bit
\item La plaquette technique et commerciale du produit ;
\item la documentation d'utilisation ;
\item le dossier de tests ;
\item la documentation décrivant l'organisation qualité du fournisseur du
produit.
\eit
La certification sert à faire valider la conformité d'un système qualité aux
normes ISO 9000 par un organisme compétent et indépendant et permettant de
donner une assurance écrite qu'un produit, un processus ou un service est
conforme aux exigences. Dans le cas d'un laboratoire, on ne parle pas de
certification mais d'accréditation.

\section{Dossier de validation}
Ce dossier se décompose en 3 sous-rapports :
\bit
\item Le rapport de spécification ;
\item le plan de validation ;
\item le rapport de validation.
\eit
Le rapport de spécification a pour objet de fixer les spécifications
fonctionnelles du logiciel. On y trouvera les exigences de qualité,
d'exploitablité, de fonctionnalité, d'utilisabilité et de validation. De même,
seront incluses les obligations de moyens et/ou de résultats.

Le plan de validation doit contenir l'échéance et les différentes étapes
inhérentes au processus de validation.

Le rapport de validation rend compte de la procédure de validation.

\section{Dossier d'intégration}
Ce dossier présente :
\bit
\item Le rapport de conception ;
\item le plan d'intégration ;
\item le plan de développement ;
\item le manuel d'utilisation ;
\item le manuel d'exploitation ;
\item le rapport d'intégration.
\eit
Le rapport de conception répertorie l'ensemble des choix fait lors de la
conception, et les diverses contraintes en découlant. Il doit aussi bien
spécifier les fonctionnalités et l'utilisabilité du logiciel, que les
contraintes techniques et matérielles.

Le plan d'intégration présente les différentes étapes du processus
d'intégration.

Le plan de développement décrit les points importants du développement, en
particulier les différents timings exigés pour aboutir à la phase de
certification.

Le manuel d'utilisation décrit l'ensemble des fonctionnalités du logiciel mises
en place pour l'utilisateur.

Le manuel d'exploitation indique les procédures de mise en {\oe}uvre de
l'application (installation, désinstallation, configuration).

Le rapport d'intégration et le rapport final décrivant en détail les choix des
concepteurs.

\section{Dossier d'analyse}
Ce dossier est comprend :
\bit
\item Le rapport d'analyse ;
\item le plan de test unitaire ;
\item le rapport de test.
\eit
Le rapport d'analyse est directement issu de l'analyse du projet à partir des
méthodes conventionnelles (Merise, UML, ...). Les informations incluses sont
dites descriptives et non techniques. Seul le type d'algorithme utilisé pour
certaines taches est indiqué, mais aucune forme d'implémentation n'est précisée.
Les interfaces homme-machine font partie intégrante de ce rapport, et sont
présentées comme définitives au niveau contenu (avec mise en place des
différents contrôles : boutons, fenêtres, etc.).

Le rapport de test indique quels tests ont été effectués, quels ont été les
résultats obtenus et quelles décisions / modifications ont été faites en
fonction de ces résultats.

\section{Dossier de programmation}
Ce dossier comporte les différentes étapes au niveau programmation, c'est à dire
implémentation. On y trouvera l'ensemble des informations en rapport avec la
maintenance du logiciel et concernant son évolutivité. Ce dossier doit contenir
une présentation claire du code source, mais ne doit pas s'en contenter. En
effet, viennent s'y ajouter les rapports sur les performances obtenues, les
différents bogues (correctibles ou non), et les parties n'ayant pas été
programmées avec la raison : non utilité ou manque de compétences appropriées.

\chapter{Critères de qualité d'une documentation}
On distingue dès le début deux niveaux d'analyse : la forme et le contenu du
document. Bien que les deux concepts soient analysés indépendamment l'un de l'autre, nous
sommes obligés de passer par une analyse de la forme pour pouvoir identifier le
contenu.

On retrouve ces deux aspects définis plus préciséments chez H. Jelitte qui
introduit la différence entre la structure formelle externe d'un texte et sa
structure sémantique interne. L'analyse de la structure formelle
correspond à l'évaluation de la cohésion du texte. L'analyse de la structure
sémantique repose sur la comparaison du contenu informationnel du
texte au contenu référentiel.


Compte tenu du but de communication qui découle du type de document, un certain
nombre de critères qui peuvent parfois qualifier, et le forme, et le contenu du
document, ont été déterminés. Ces critères sont soit normatifs, soit justifiés
par le profil du lecteur final qui doit appliquer le document.

% TODO mettre la figure ?

\section{La complexité}
La complexité est analysée pour juger de l'intelligibilité d'un document. Elle
est appréciable au niveau de la forme et du contenu. Le principe retenu dans le
cas de ce critère considère que moins les moyens linguistiques utilisés sont
complexes, plus le degré de la compréhension augmente. On recherche donc la
simplicité dans la formulation.

\section{La clarté}
La clarté est également un critère qui permet d'évaluer l'intelligibilité d'un
document. Le rédacteur doit utiliser les expressions les plus claires possibles
pour permettre au lecteur d'identifier aisément et sans ambiguïté les concepts
évoqués dans le document qui doit le guider. L'analyse de la clarté repose
également sur une appréciation de la forme.

\section{Les normes}
L'évaluation du respect des normes correspond au contrôle des règles qui ont été
définies par le métier et auxquelles un rédacteur est soumis à priori. Il s'agit
de conventions d'écriture et de l'énonciation obligatoire de certains thèmes. Le
respect de l'application des normes peut donc être évalué au niveau de la forme
et du contenu du document. Elles sont strictement dépendantes des habitudes de
la communauté au sein de laquelle sont rédigés les documents. De ce fait, elles
peuvent ne pas exister.

\section{La précision}
Le but de tout document technique étant de transmettre des informations
nécessaires à l'exécution d'une tâche, chaque imprécision constitue une source
d'erreurs potentielles dans le projet. Soit elle laisse au lecteur le libre
choix entre plusieurs modes d'exécution possibles, ce qui est rarement le but
recherché, soit elle nuit à la compréhension de l'information transmise. Le
critère de précision est évalué au niveau de la forme et du contenu du document.

\section{La complétude}
La complétude se décompose en réalité en deux sous-critères : le premier est
évalué par une analyse du document hors contexte, c'est à dire sans connaissance
du domaine dont il traite ; le second dépend en grande partie du but fixé de la
communication.

Le premier critère est celui de la complétude définitoire. Il permet de
contrôler l'intelligibilité du document.

Le deuxième est celui de l'exhaustivité thématique. Il mermet de contrôler si
toutes les informations attendues sont contenues dans le document.

\section{La pertinence}
Le critère de pertinence fait partie de l'analyse du contenu du document. Il
s'associe au critère de complétude. Au lieu de détecter les lacunes
informationnelles dans un document, il s'agit d'itentifier les informations
superflues. Le superflu paraît moins nuisible que l'incomplétude, mais
représente tout de même une source d'incompréhension, car il augmente
inutilement la charge informationnelle du document. Comme le critère de
complétude, la pertinence peut être évaluée à deux niveaux. Soit on analyse la
pertinence par rapport aux informations attendues, soit on l'évalue sans aucune
référence.

\section{L'exactitude}
L'exactitude est un critère qui concerne à la fois la forme et le contenu du
document. Au niveau du contenu on trainte l'incompatibilité d'une information
par rapport à une autre, c'est à dire le cas où il y a contradiction.
L'exactitude au niveau de la forme correspond à la conformité de la rédaction
aux règles typographiques de la langue française.

\chapter{Défauts d'une documentation}
\section{La sur-spécification}
Il s'agit d'une défaut qui survient lorsque le document ne peut être écrit à
partir de ses spécifications seulement, lorsqu'il comporte trop de bruit
(parties du document sans intérêt : \textit{impertinence explicite}) ou de
silence (par omission, absence : \textit{partinence implicite}).

\section{L'ambiguïté}
Ces défauts sont marqués par la contradiction, les v{\oe}ux pieux et le bruit,
ainsi que les références à des documents externes (aussi bien les références
explicites que celles implicites).

\chapter{Enjeux de la maîtrise de l'ingénierie logicielle}
Les logiciels tiennent dans les économies des pays développés une place
considérable. On les trouve désormais à peu près partout. Rares en effet sont
aujourd'hui les produits grand public qui n'en contiennent pas. Et dans les
systèmes sophistiqués, ils ont pris une importance que le public ne soupçonne
pas. Une des premières caractéristiques des logiciels est donc qu'ils sont
présents partout.

Une deuxième, de plus en plus évidente, est qu'ils sont porteurs de gros
risques. Ces risques sont de deux ordres. D'abord les risques liés aux produits,
dont les malfonctions peuvent causer de graves dommages aux biens et aux
personnes. Ensuite les risques liés à l'absence de maîtrise des processus de
développement. Ces derniers risques étant la cause principale des premiers, et
se traduisant en outre par de graves dérives de coûts et de délais, quand ce
n'est pas par un abandon pur et simple. \`A titre d'illustration, les firmes
américaines dépensent chaque année quelques 250 milliards de dollars en
logiciels.

Et un autre péril se profile à l'horizon : pour certains pays en voie de
développement industriel, ou développés mais peu présents sur les marchés
internationaux, le logiciel représente une occasion favorable intéressnte de par
les faibles investissements matériels et d'infrastructure qu'il nécessite. Ceci
explique les efforts considérables consentis par ces pays en matière de
formation et de soutien aux entreprises de ce secteur. 

Ce qui soumet les pays développés à une double menace :
\bit
\item Interne, par l'absence de maîtrise d'une technique essentielle pour leur
économie ;
\item Externe, par l'irruption à très court terme d'une concurrence étrangère
redoutable en terme de coûts et de qualité.
\eit
La Défense est aussi un grand acheteur de logiciels. Elle est tout
particulièrement sensible aux risques, tant en matière de coûts/délais qu'en ce
qui concerne la sécurité des produits finis qu'elle commande. Enfin, c'est un
secteur qui, même dans les pays les plus libéraux, ne peut que rester étatique
et donc animé d'un esprit de service de la collectivité tout entière.

C'est ainsi que nous voyons le département de la défense des \'Etats-Unis
financer entièrement un institut d'ingénierie du logiciel fort de deux cents
personnes et de renommée mondiale - le Software Engineering Institute de
l'université Carnegie-Mellon en Pennsylvanie, fameux entre autres choses pour
son modèle d'évolution des capacités logiciel, le SW-CMM, et prendre en 1993
l'initiative de la création d'un conseil national du logiciel (le \textit{National
Software Council}), chargé de fédérer les efforts des industries et
administrations en vue de la survie de l'industrie américaine du logiciel.

C'est ainsi également que nous avons vu le Ministère de la Défense du
Royaume-Uni investir très lourdement dans la méthodologie TickIT d'évaluation
tierce partie des industriels, et plus récemment dans le projet ISO/SPICE basé
sur l'auto-évaluation / auto-amélioration des développeurs de logiciels.

\chapter{Différentes approches face aux standards existants}
Il y a bien longtemps que l'on répète que, pour avoir l'assurance de la qualité
d'un logiciel, il ne suffit pas de s'intéresser au produit lui-même, mais qu'il
convient aussi et surtout de regarder la manière dont ce logiciel est produit,
autrement dit les processus en place chez l'industriel chargé du développement.

Les approches pour atteindre ce but ont beaucoup varié.

\section{L'approche contractuelle <<dure>>}
Elle consiste pour le client à imposer à l'industriel, jusque dans le détail, la
manière dont il doit s'y prendre pour réaliser le logiciel objet d'un contrat.
C'est l'approche, dite <<méthodologique>> de la DOD-STD-2167A et de la GAM-T17
(v2).

Cette approche à deux inconvénients. Le premier est qu'un industriel posède en
général sa propre façon de travailler, et qu'il peut difficilement en changer au
gré des contrats. Le deuxième est qu'il n'existe pas, semble-t-il, de
méthodologie universelle, valable pour tous les types de logiciels et compatible
avec toutes les techniques de développement, présentes et à venir. Ainsi le
cycle de vie <<en cascade>> ou <<en V>> des deux normes précitées s'est révélé
peu compatible avec les nouvelles méthodes de développement orientées objet.

\section{L'approche par évaluation tierce partie}
Elle consiste à auditer les fournisseurs potentiels de logiciel pour tenter de
s'assurer qu'ils ont la capacité requise pour développer des logiciels de
qualité dans dérives de coût ni de délai. Cette approche présente un défaut
intrinsèque et deux autres défauts plus conjoncturels.

Le défaut intrinsèque est que cette approche instaure \textit{ipso facto} entre
auditeur et audité un climat de défiance mutuelle qui n'est pas très favorable à
une appréciation parfaitement réaliste et sereine des capacités réelles d'un
développeur de logiciels.

Les deux défauts conjoncturels viennent du fait que ce type d'évaluations a été
fait jusqu'ici essentiellement par rapport à des référentiels extrêmement
succints (ISO 9001, 9000-3, AQAP-13...). D'où une marge d'interprétation très
grande pour les auditeurs, qui permet de douter très sérieusement de
l'homogénéité de telles évaluations. D'où le caractère purement binaires de ces
évaluations qui, quelle que soit leur issue, ne donnent à l'audité ni
description précise de son état actuel (ce que l'on appelle aujourd'hui
\textit{niveau de maturité}), ni carte détaillée des mesures à prendre pour
progresser.

\section{L'approche contractuelle <<souple>>}
C'est essentiellement celle des normes de la série ISO 12207 et de la norme
militaire US MIL-STD-498 qui a pris la suite de la DOD-STD-2167A et qui se veut
fondée sur la 12207. L'objet de ces normes est essentiellement de fournir aux
clients et aux fournisseurs un langage commun, sous forme d'une carte du
terrain, aussi précise que possible, mais sans imposer au développeur sa façon
de travailler (en particulier, sans prescrire un modèle spéficique de cycle de
vie). On échappe ainsi aux deux inconvénients relevés plus haut à propos de
l'approche contractuelle <<dure>>, et le client doit pouvoir ainsi disposer
d'une très grande visibilité sur son fournisseur. Cette approche a néanmoins
l'inconvénient d'être formelle et par là-même statique. En effet, il lui manque
une dimension évolutive. Elle ne tient pas compte du niveau réel de maturité
d'un industriel à un moment donné et de la nécessité qu'il peut y avoir pour lui
à s'améliorer, progressivement et de façon méthodique.

\section{Les approches à <<niveaux de maturité>> : CMM et SPICE}
Ces approches conservent l'acquis, en termes de description fine des processus,
de l'approche précédente, à laquelle elles ajoutent une dimension dynamique très
réaliste. Elles partent du principe que si un industriel, à un moment donné, se
trouve à un niveau de maturité $n$, il n'est pas raisonnable d'espérer qu'en
quelques mois il pourra se hisser au niveau $n+2$. Elles permettent à un
développeur de logiciel non seulement de se connaître de manière très précise,
mais encore de déterminer finement quelles actions d'amélioration il peut
raisonnablement entreprendre, et dans quel ordre, s'il souhaite élever son
niveau de capacité. Il n'est donc pas étonnant que ces approches, suscitées au
départ par les clients, aient été très vite récupérées par les fournisseurs, qui
ont compris qu'ils tenaient là des outils irremplaçables pour :
\bit
\item se connaître,
\item s'améliorer,
\item survivre !
\eit
D'où la très nette orientation vers l'auto-évaluation qui a été prise par ces
approches au fil du temps (sans pour autant qu'elles excluent les évaluations tierce parties)

\chapter*{Conclusion}
\addcontentsline{toc}{chapter}{Conclusion}
Si les \'Etats-Unis s'inquiètent de la survie de leur industrie du logiciel, la
France n'a-t-elle pas dans ce domaine quelques soucis à se faire ? La réponse
est bien évidemment \textit{oui}.

Le logiciel est devenu une affaire planétaire. Sur le plan des techniques et des
outils, bien sûr. Sur le plan des marchés, évidemment. Mais aussi sur celui des
méthodes de management et de maîtrise de son développement.

Participons-nous suffisamment aux travaux internationaux qui visent à recueillir
et à codifier l'état de l'art dans ce domaine ? Il semble bien que non, et que
la plupart du temps nous nous contentions d'y jouer un rôle d'observateur, ce
qui est bien insuffisant pour un pays tel que le nôtre. Il est vrai que, grâce
essentiellement aux efforts de l'AFNOR, la substance de ces travaux est assez
bien diffusée à l'intérieur du tissu industriel français. Mais il ne suffit pas
d'être au courant. Nous devons en tirer toutes les conséquences qui s'imposent
pour le maintien de la compétitivité internationale de nos industriels et la
meilleure satisfaction de nos donneurs d'ordres.

Une coordination entre tous, donneurs d'ordres, industriels grands et petits,
est certainement indispensable. Il est sans doute regrettable qu'il n'existe pas
en France de point focal analogue à ce que peuvent être aux \'Etats-Unis le SEI
et au Canada le Centre de Génie Logiciel Appliqué de Montréal. La récente
création à Bilbao d'un European Software Institute se propose à l'évidence de
constituer un tel point focal à l'échelon européen. Mais l'existence d'un relai
français, si modeste fût-il, paraît nécessaire, ne serait-ce que pour servir
d'interface culturelle, et montrer l'interêt que porte notre pays à cette
industrie phare.

Le rôle de l'enseignement supérieur est aussi à souligner. Dans les pays
qui ont fait du logiciel une de leurs priorités, il joue un rôle majeur dans
l'entretien et la diffusion d'une culture logicielle solide.

C'est donc un triple partenariat entre donneurs d'ordres, industriels et
enseignement supérieur, autour probablement d'un pôle institutionnel à créer,
qu'il nous faut travailler au plus vite.

\end{document}
