Retour aux origines du RAD

Le livret (600 Ko) : RAD Contexte d'émergence

Origines et fondements de la méthode RAD

Ce chapitre doit être considéré comme une annexe historique à l'usage d'étudiant ou de chercheurs. Il est  sans utilité dans la mise en oeuvre immédate de la méthode. Il représente un exposé du contexte stratégique, organisationnel et technologique qui a justifié l’émergence de la méthode RAD. Sa lecture préalable aux autres chapitres est conseillée à tous ceux pour qui le RAD est une nouveauté et qui souhaiteraient prendre connaissance de ses origines et de ses fondements.

RAD, origines anglo-saxonnes

Vers la fin des années 80, James Martin présente en Amérique du Nord une approche de développement rapide d'applications : le RAD.

En 1991, il publie le premier ouvrage sur le sujet qui devient la " bible " du RAD.

De 1991 à 1994, ce livre en anglais est le seul texte disponible. A son origine, il ignore Windows, l’architecture client-serveur et l'intégration technologique.

Vers le milieu de la décennie 90, les bases d'une approche plus spécifique au Client-Serveur TCSM (The Client-Server Method) sont posées. Cette évolution intègre au RAD une phase de conception technique et une phase de transition organisationnelle afin de former les utilisateurs à la nouvelle complexité du poste client.

En Angleterre, le RAD est immédiatement considéré comme une méthode performante indispensable à l’organisation du développement d’applications modernes. En 1994, un consortium est créé pour le promouvoir et le développer dans un cadre d’échanges interentreprises. Cette initiative aboutit à la méthode DSDM dont le cycle totalement itératif se distingue de celui du RAD.

Le RAD, pour des raison de cohérence systémique, préconise un cycle semi-itératif.

RAD, émergence francophone

Au Québec comme d’ailleurs dans le reste du Canada, la méthode RAD est utilisée depuis la fin des années 80. En France, de 1991 à 1995, seuls, deux ou trois textes de journalistes rapportent, en quelques paragraphes, la parution d'un livre de James Martin intitulé RAD publié en 1991 aux Etats-Unis et jamais traduit. Une ou deux sociétés de services connaissaient peut-être l'existence du RAD et comptaient en profiter, mais aucune ne publie sur le sujet.

En décembre 1993, Jean-Pierre Vickoff qui pratiquait comme consultant au Canada arrive en France. Il constate que le RAD est inconnu de ses collègues. Il le met en œuvre à la SEITA, puis propose une conférence en septembre 1994 à l'Association française des utilisateurs de systèmes Unix (AFUU). L'AFUU accepte et commande une intervention pour son Uniforum de mars 1995 au CNIT.

Les premières et seules publications techniques définissant de manière détaillée les principes du RAD parurent en France à partir de 1994. Elles ont toutes Jean-Pierre Vickoff pour auteur.

Les principaux magazines les ayant publiées sont les suivants :

  • Informatique Client-Serveur (octobre 1994)  " Adaptez vos acquis méthode (SDM/S, Merise) et produisez en RAD " ;
  • Le Monde Informatique (623, mars 1995) " Il faut marier les approches " ainsi que " Le RAD à la Seita " puis (629, avril 1995) " Un engagement RADical " ;
  • Logiciels et Services (avril 1995) " Le RAD, Méthode des développements performants " ;
  • Informatique Professionnelle (juin 1996) " Les possibilités de la méthode RAD " ;
  • Logiciels et Systèmes (novembre 1996) " Le RAD , méthode ou anti-méthode ".
  • Ces articles techniques et communications proposés à la communauté professionnelle représentaient plusieurs dizaines de pages consacrées à la méthode RAD et en définissant concrètement les principes.

    Parallèlement, la revue Client-Serveur (Canada) propriété de JPV (ISSN 1195-8022) et renommée RAD/CSO pour sa version publiée en France, faisait paraître cinq numéros entre septembre 1994 et septembre 1995. Ils étaient distribués trimestriellement sur un fichier couvrant les 1200 plus grandes entreprises de la région parisienne. Soit environ 32 pages, entièrement consacrées à la promotion de la méthode RAD.

    Toujours en 1995, un rapport de 300 pages intitulé Développement Rapide d'Applications (RAD) fut déposé à la SGDL. Il fit l'objet de plusieurs publicités et fut vendu aux grands comptes (EDF, le CID, La Poste, GIAT, France Télécom, la Macif, etc.).

    C'est après, et seulement après ces efforts, que la presse et les entreprises de services ont commencé à s'intéresser au RAD. Cet intérêt aboutit, dans le dernier semestre 1996, à la publication de plusieurs ouvrages et à la vague de références à laquelle on assiste actuellement.

    En ce qui concerne le terme " RAD " appliqué à la méthode, il suffit d'observer la triste réalité de l'explosion de l'offre, pour comprendre que ce mot va devenir pour beaucoup synonyme d'échec et de déception. Certaines sociétés vendent des services ou des cours de RAD et le font avec respect de la méthode. Par contre, d’autres, des plus illustres, vendent n’importe quoi ou assimilent cette méthode puissante à du prototypage engageant ainsi leurs clients confiants dans des voies qui conduisent à l’échec de projets.

    RAD, contexte et évolution

    La suite est une actualisation du rapport rédigé à partir de 1992 par Jean-Pierre Vickoff et publié en 1994 par MGI (dépôt SGDL), puis réédité dans une édition commercialisée en librairie par Macmillan en 1996. Cette édition est épuisée et ne sera plus rééditée malgré de nombreuses demandes de diverses origines, françaises comme étrangères et de professionnels autant que d’étudiants). En voici de brefs extraits toujours d’actualité.

    Développement : " état des lieux "

    Au début des années 90, les organisations consacraient entre 40 % et 75 % de leurs ressources de développement à la maintenance de l'existant. Le " bug " de l’an 2000, le passage à l’euro et maintenant la RTT ont encore accru ce pourcentage à la fin de la décennie.

    En conséquence, le portefeuille des besoins " en attente " accuse début 2000 plus de quatre années de retard. D’autre part, on constate, dans la plupart des cas, un doublement du coût de réalisation des grands projets par rapport à leur budget prévisionnel. Et il serait de mauvais goût de citer le pourcentage (avoué) de projets qui se sont enlisés lors de développements classiques. Certains ont même été abandonnés durant la phase de déploiement (31%). Les besoins avaient changé ou avaient été mal évalués un an ou deux plus tôt, lors de la phase d'analyse (53%). On comprend alors l'importance d'un développement rapide et d'une relation permanente avec l'utilisateur.

    La vision " utilisateur " des problèmes posés par l'informatique est d'ailleurs édifiante et s’exprime à travers :

  • des délais avant réalisation ou maintenance évolutive s’exprimant en mois et parfois en années ;
  • des applications partiellement inutilisables  caractérisées par des fonctionnalités inutiles ou absentes ;
  • des coûts de développement et d’exploitation prohibitifs ;
  • et, pour résumer la problématique d’un responsable opérationnel, " un cycle de développement incompatible avec le cycle de vie des nouvelles applications et les impératifs stratégiques de l’entreprise ".

    Ce triste constat a eu pour effet positif de concourir à l'émergence d'une responsabilisation grandissante de la maîtrise d'ouvrage, qui a poussé, par ricochet, les directions informatiques à rechercher l'évolution de leurs méthodes de développement.

    Nouvelle vision de la fonction Informatique

    Une enquête réalisée auprès de 130 DSI a révélé l'émergence d'une vision neuve et stratégique de leurs fonctions. Parmi les éléments caractéristiques de cette évolution, l'appui à la recherche de compétitivité est cité en premier. Cette globalisation du champ d'intervention va de pair avec un recouvrement des fonctions d'organisation. On note une répartition plus équilibrée des responsabilités techniques, économiques et financières entre la maîtrise d'œuvre et la maîtrise d'ouvrage.

    Les éléments déterminants du changement s'avèrent liés à des attitudes nouvelles en terme de responsabilisation des utilisateurs (figure 1) et à l'émergence d'un poste de travail puissant et moderne utilisant toutes les possibilités de la bureautique communicante.

    Pour 80% des DSI interrogées, l'informatique devrait être un élément de cohésion dans l'entreprise ; ce n'est vrai que pour 32 % des cas. Seulement la moitié des directions générales seraient conscientes du caractère stratégique de la fonction informatique.

    Le retour sur investissement souhaité par 83% des DOP serait assuré pour seulement 39% des projets. Malgré cela, un seul tiers de ces DOP considèrent la fonction informatique comme un service externalisable. Par contre, la majorité des DOP souhaitent considérer leur DSI comme une société de services interne, chargée de la cohérence, de la coordination et de la normalisation des produits et services informatiques.

    Figure 1. — SI : évolution vers la complexité

    Technologie et système d’information

    La technologie déterminante en termes d’amélioration de la qualité est certainement la micro-informatique. Devenue une nécessité opérationnelle dès les années 70, l'informatique de gestion découvre au début des années 80 le décisionnel, les micros, les réseaux, les communications rapides et les architectures Client-Serveur. La décennie 90 voit émerger la prédominance de la " Net " économie et des exigences croissantes d’utilisateurs avertis.

    A l’aube du 21ème siècle, l’informatique est consacrée " moteur de différenciation concurrentielle ".

    Dans le même temps, l'impact positif de la technologie sur les temps de développement est absorbé par la complexité de l’interface et la richesse fonctionnelle des applications. Ce constat et la crise économique conduisent les décideurs à se poser la question de fond : " Comment améliorer la productivité et réduire les coûts ? " Technologie et méthode s'associent alors pour fournir une réponse : RAD

    RAD, la réponse méthodologique

    Le RAD a pour objectif principal de réduire le projet en charge (gain d'argent) et en délai (gain de temps). Cette compression du cycle de développement présente de nombreux avantages en termes de qualité " indirecte ".

    La deuxième ambition du RAD est l'objectif de qualité " directe ".  Le RAD garantit l'adéquation parfaite du produit fini aux exigences de l'utilisateur, il en résulte la réduction des coûts de maintenance applicative et corrective. Les autres objectifs du RAD sont liés à l'engagement et à la satisfaction des utilisateurs. Le RAD permet et impose naturellement une participation active et une motivation des futurs clients de l'application. Ce point à lui seul justifierait l'utilité du RAD. Une application conçue par les utilisateurs et réalisée sous leurs directives est conforme à leurs attentes et n'encourt pas le rejet.

    Les fondements sont clairs : " COMMUNICATION, ENGAGEMENT ET MOTIVATION des partenaires dans le projet ". Si ces principes peuvent paraître simplistes, les résultats sont convaincants. Des applications qui s'enlisaient dans des approches conventionnelles aboutissent sans problème, une fois le RAD engagé. Par contre, l'usage des meilleurs outils logiciels (AGL) d'aide à la conception et au développement s'impose sans concession (figure 2).

    Figure 2. — Outils AGL : les meilleurs et les plus légers

    Systémique, réingénierie, projets de SI

    Les approches systémiques de développement se définissent par rapport à leur projet de structuration plutôt que par leur objet : l'application.

    La France a été, durant ces vingt dernières années, une plate-forme de test pour Merise. Le problème méthodologique français qui en résulte se situe dans son incapacité à réagir à une évolution rapide. L'exemple est particulièrement marquant en ce qui concerne l'intégration technologique par rapport aux niveaux d'abstraction et le cycle de vie par rapport à la rigidité du cadre systémique.

    Dans les années 60, les experts considéraient les choix stratégiques comme découlant de la structure des organisations (la fonction crée l'organe). Les années suivantes démontrèrent le réductionnisme de cette conception, qui négligeait les facteurs organisationnels et les pressions externes.

    Aujourd’hui, l'évolution technologique, caractérisée par l'introduction de la micro-informatique et de Windows, s'impose fondamentalement comme le facteur structurant en termes d’organisation. Mais, c'est seulement avec les nouvelles technologies applicatives et les architectures distribuées les supportant que la fameuse décomposition en sous-systèmes opérants et sous-systèmes de pilotage prend une réelle dimension pratique.

    La critique majeure faite aux méthodes de conception traditionnelles, réside dans leur obligation de se calquer sur une organisation stabilisée. Cet aspect va à l'encontre d'une obligation actuellement cruciale pour toutes les organisations : l'évolution.

    Dans les secteurs où l’évolution technologique est rapide et dans le cas d'entreprises soumises à une forte pression commerciale, l'instabilité dans le choix des systèmes d'information conduit à une réduction drastique de la durée de vie des composants applicatifs. Les méthodologies s'adaptent et s'appuient sur l'usage d'outils puissants (AGL) pour garantir le maintien de la cohérence systémique. Ces opérations de perpétuelle adaptation remplacent progressivement la traditionnelle maintenance évolutive et aboutissent aussi bien à la production d'applications stratégiques que "Kleenex". Sur le plan organisationnel, il en résulte un besoin de flexibilité égal à la réactivité requise pour obtenir un service concurrentiel.

    Les domaines du RAD et de l'Objet se définissent donc en fonction d’une réponse et non pas d’une structure.

    RAD et qualité de service

    Le développement des systèmes d'information et les processus d'amélioration continue de la qualité s'inscrivent dans un même courant de pensée (figures 3, 4, 5). La communication est leur dénominateur commun, et le RAD constitue l'outil privilégié de leur mise en œuvre.

    Figure 3. — RAD : intégration au courant Qualité

    La qualité est à la fois une tendance, un courant et un concept sur lesquels repose le futur de l’économie de marché. Cette notion de qualité recouvre dans la pratique deux réalités : le management par l'amélioration continue de la qualité (MTQS) et la recherche d'une certification qualité (ISO 9000). On ne confond pas la maîtrise de la qualité, qui est un fait, et l'assurance qualité qui est un plan.

    Le vrai défi de la recherche d'amélioration continue de la qualité concerne la rupture des barrières de communication.

    Le plus souvent, les personnes au cœur des dysfonctionnements ne les voient pas, et ceux qui les subissent ou en ont connaissance ne souhaitent pas en parler par solidarité ou par crainte. Dans certaines organisations, l'anonymat d'une simple boîte à idées a débloqué des situations inextricables en servant de base positive au travail des équipes d'amélioration. Le plus important dans une opération d’amélioration continue de la qualité reste la motivation des participants, qui ne doit pas être déçue.

    Figure 4. — Méthode RAD : inclusion de diverses techniques

     

    Le MTQS repose sur des choix d'organisation et de communication (pris dans le sens des relations humaines). La certification, au-delà d'un " moteur pour la qualité ", est avant tout la reconnaissance d'une maîtrise documentaire formalisée. Les deux aspects ne sont pas incompatibles, bien au contraire. Il n'en demeure pas moins que les experts évitent d'engager simultanément des projets visant à la maîtrise des deux préoccupations. De nombreux ouvrages traitent de ces sujets (bibliographie Qualité), le RAD les intègre naturellement :

  • par ses modes opératoires de communications privilégiant l'utilisateur, dans une relation de spécification-validation permanente, la méthode RAD s'assure la qualité opérationnelle (MTQS) ;
  • par le recours systématique aux AGL et à la bureautique communicante, le RAD garantit les bases d'une qualité documentaire au-delà de ce que l’on observe généralement lors de développements classiques.
  • Ainsi, l'informaticien s'adapte à la double nécessité d'un procédé documentaire pour réaliser un produit lui-même parfaitement documenté (aide contextuelle, hypertexte, on-line).

    Figure 5. — Trilogie du développement industrialisé

    L'aspect documentaire est, en RAD, un point qui diffère fondamentalement des techniques classiques. La documentation s'élabore et se valide en direct sur des micros (portables), le plus souvent sous une forme graphique. Point primordial, elle est conservée par des outils spécialisés et utilisée dynamiquement en cours de projet. Car il est inconcevable de " penser RAD " sans disposer des outils les plus performants pour concevoir et développer :

  • les outils de bureautique communicante (et bientôt des AGL de Cadrage) permettent d’obtenir " en direct " l’expression exigences et leur validation ;
  • les AGL de conception font évoluer en temps réel les modèles graphiques et la documentation correspondant à la phase de conception haute ;
  • les AGL de réalisation gèrent la documentation technique lors du prototypage, directement dans le code source, au niveau de chaque module, objet ou événement.
  • La souplesse de ces outils est ensuite démultipliée grâce à l’interactivité obtenue par le couplage des micros à des matériels de vidéoprojection. Cette instrumentation autorise de réaliser les opérations de spécifications et de validation immédiate, avec la participation active de l'utilisateur.

    RAD : stratégique, technologique et organisationnel

    Le développement d’applications doit désormais s’inscrire au cœur d’une Méthode de Conduite de l'Evolution.

    La trilogie stratégique, technologique et organisationnel subsiste, mais l'importance déterminante des éléments est inversée. La stratégie s'appuie sur la technologie, ensuite l'organisation s'adapte. L'évolution technologique conditionne désormais l'organisationnel. Nous sommes au cœur de la réingénierie des procédés " métier ".

    Les nouveaux développement remettent en cause l'organisation et les méthodes. Ils impliquent l'utilisateur réel dans le pilotage et la réalisation des nouveaux systèmes. A l'inverse de Merise ou de SDM/S, le RAD en réalisation ignore les comités et les validations en cascade, et spécifie en direct l'interface et les fonctionnalités. Le transfert d'informations vertical et hiérarchisé fait place à une coordination transversale. Ces nouveaux développements s'inscrivent systématiquement dans le prolongement d'un plan d'amélioration continue de la qualité de service.

    La réingénierie des procédés optimise l'organisation, ses communications, ses données et ses traitements avant toute opération d’automatisation

    Méthode RAD et relations interpersonnelles

    Le RAD, dans toutes ses phases, implique la communication de groupe. Des réunions de travail entre utilisateurs et informaticiens s'organisent périodiquement. Leur fréquence est dépendante de la typologie du projet et de la localisation géographique des utilisateurs. Une planification stricte est établie. Les objectifs formels sont communiqués préalablement aux réunions.

    La conduite d'entretien nécessite de préférence un " animateur " indépendant (hors équipe de réalisation et groupe utilisateur). Un profil " méthode " formé au RAD et aux techniques d'entretien est souhaitable. Dans un petit projet, on donnera une formation complémentaire à la ressource ayant le profil le plus proche.

    La " multi disciplinarité " des acteurs, dont certains ne sont pas informaticiens, nécessite une forme innovante de coordination.

    Suivant le niveau de détail, les équipes d'utilisateurs se rétréciront et se spécialiseront. Cela s'applique à la conception haute (Joint Planning Requirement Team), à la conception détaillée (Joint Application Design Team) et à la réalisation (Construction Assistance Team). Le RAD se qualifie alors de " processus orchestre " où interviennent à tour de rôle les spécialistes que les fonctionnalités ou la technologie nécessitent.

    Pour les analystes, les programmeurs et les autres catégories d’informaticiens confrontés aux enjeux de l'évolution, un difficile et long apprentissage devient subitement synonyme d'inefficacité. Les responsables méthodes se transforment alors en " ayatollah " et freinent toute évolution contraire au dogme. Ce problème se pose également pour les experts Unix, Novell, etc., qui se trouvent confrontés à Windows NT. Un combat d'arrière-garde identique se profile pour les développeurs classiques, débordés par un Visual Basic qui les dépouille de tous les artifices de la complexité. Mais que l'on ne se leurre pas sur ce point, une application Client-Serveur multicouches nécessite une réelle expertise de développement et d'architecture.

    Pour revenir aux méthodes, ce n'est pas Merise 2 ou même Merise Orienté Objet qui apporte une solution à ce dilemme. On assiste au contraire à une multiplication des modèles et des formes de notation. Ces prolongements offrent des réponses intellectuellement satisfaisantes pour des cas de figure particuliers, mais ne simplifient pas la mise en œuvre. De telles approches sont trop lourdes pour la majorité des applications. Passé un seuil limite de rigueur dans les formalismes, les développeurs et les SGBD ne suivent plus.

    RAD, architectures et technologies

    La performance de la méthode est liée à celles des outils et des architectures. Mais à la recherche d’une définition pour " Client-Serveur ", une réponse technique (figure 6) serait sans signification. Abordons le sujet sous un autre angle : que souhaitons-nous obtenir de l'informatique ? La réponse est claire : " disponibilité totale de l'information à travers des applications simples à utiliser ". Pour préciser les conditions réalistes de cette obtention : " le meilleur service au moindre coût ".

    Dans un premier temps, la réduction d'architecture déporte les applications décisionnelles des grands systèmes vers des réseaux de micros ; le Client-Serveur offre alors la possibilité d'accéder aux données de bases avec de nombreuses applications complémentaires. Cette information est ensuite présentée sous les formats sophistiqués et le plus souvent graphiques, que requiert la gestion des organisations modernes. Il en découle le postulat suivant : il n'y a pas de vrai Client-Serveur sans Windows, et le RAD est avant tout du développement Client-Serveur sous Windows.

    Figure 6. — Modèle répartition client-serveur (Gartner Group)

    Dans une organisation efficace, toute information est intégrée au système ; elle est structurée et disponible en toute sécurité. Chacun dispose des outils spécifiques qui permettent de l'utiliser selon ses besoins.

    Pour réaliser économiquement un système de traitement répondant à ces critères, il faut utiliser des applications communicantes. En résumé, les employés, cadres, secrétaires, ingénieurs et dirigeants disposent de l'information corporative au travers de tableurs, de traitements de texte, d’outils de graphisme ou de PAO, etc . Le seul interface qui offre ces possibilités est Windows et une application qui ne supporte pas l’intercommunication n'est pas " Windows ". La connectivité annonce la fin des outils de développement " intégrés " et des systèmes propriétaires. Le RAD s'appuie sur ces techniques pour accroître sa performance.

    Nous entrons dans une ère où la technologie supplante l'homme dans l'aboutissement de l'organisation.

    Le principe s'applique déjà à la production des services (banques, assurances, retraites, etc.) et s'étend concrètement à la presque totalité de nos activités. Dans l'entreprise confrontée à la concurrence, cette évolution est fiable et rentable. Pour l'opérationnel courant, la technique est l'alliée de l'organisation. A ce niveau, elle se révèle à la fois secondaire et primordiale. Secondaire, car toute technique est éphémère, mais primordiale, car elle permet de produire plus efficacement.

    Le grand art consiste à choisir, parmi les outils toujours plus récents et efficaces, ceux dont l'adéquation aux besoins est optimale.

    Productivité : plaidoyer pour un IHM totalement " Windows "

    L’arrivée simultanée des micros-ordinateurs et de Windows peut être considérée comme une immense action de réingénierie, car elle bouleverse, parfois fondamentalement, les méthodes de travail, l’importance de l’information manipulée et le pouvoir généralement associé à ces deux composants.

    A l’aube du bigbang, au milieu des années 1970, les 80 colonnes de la carte perforée apparurent sur un écran. Ce fut un miracle pour les opératrices qui saisissaient alors en aveugle et le début des problèmes pour les informaticiens. Sur le plan organisationnel, une révolution était en marche. En vingt-cinq ans, elle allait projeter l’entreprise appliquant les concepts édictés par Taylor, à l’ère de la créativité individuelle érigée en support de la qualité collective. Principes, dont Bill Gates, Andy Grove et leurs employés tirent si bien profit. Pour certains le progrès s’identifiait " aux soviets + électricité ", pour d’autres, il répondit soudain à l’équation " qualité + Windows ".

    Dans les sociétés évoluées, en moins de dix ans, la structure des systèmes d’information mute. Désormais, à la veille d’une ouverture totale des échanges commerciaux à l’échelle européenne et mondiale, les chances de survie d’une entreprise se jugent par le simple audit de son système d’information.

    La performance actuelle s’organise autour d’un poste de travail, intelligent par l’usage qui en est fait et générateur d’éléments de différenciation.

    Malheureusement, le passage au tout graphique n’est pas neutre sur le plan organisationnel ni techniquement aussi aisé que l’installation de Windows pourrait le laisser paraître. La transition à partir du terminal passif est généralement représentative d’une maîtrise technologique et d’une maturité organisationnelle. Comme toute forme de décentralisation, elle est à la fois le fruit d’une technologie et d’un principe qui portent le même nom : la communication. Qu’elle s’exprime par un flux de données dans un réseau de micros ou dans la formalisation d’une décision prise lors d’un entretien de groupe, la communication est à la base du partage du pouvoir, de la réduction des niveaux de contrôle et de l’avènement d’une ère de productivité généralisée. Autant de principes bien souvent considérés comme utopiques dans les entreprises françaises mais qu’il m’a été donné de voir concrètement mis en œuvre en Amérique du Nord.

    Une vision nouvelle de l’organisation, liée au besoin de satisfaction du client, émerge. Le principe de transversalité en est la clé méthodologique.

    Ce concept apparemment simpliste recouvre dans la réalité de l’entreprise une révolution dans le sens propre du terme [Renaud 1996]. Parallèlement, la notion de patron s’efface devant celle de leader, parfois charismatique. Ce dernier délègue ses pouvoirs et partage ses profits pour garantir le futur de ses ambitions (60 % des actions de Microsoft et presque autant d’Intel sont détenues par leurs employés).

    Cette recette a abouti à de telles réussites qu’elle pourrait bien constituer la voie capitaliste d’une future démocratie d’entreprise. Elle s’exprime par la formule " qualité organisationnelle + communication multimédia ".

    L’explosion du graphique (à travers Windows et la bureautique communicante) s’inscrit alors dans la montée en efficacité d’un grand courant d’évolution technologique et organisationnelle [Lorino 1997]. Pour la première fois depuis l’aube de l’humanité, un progrès peut être " accaparé " par le plus grand nombre pour infléchir une tendance lourde basée sur l’exploitation de l’ignorance. La connaissance universelle est en marche et s’affiche sur un écran de 15 pouces minimum. Gutenberg aujourd’hui se serait déclaré écologiste, aurait inventé Internet et déclaré " le futur sera graphique ou ne sera pas ", sauvant ainsi des forêts entières.

    Plaidoyer pour des réseaux " raisonnables "

    En ce qui concerne la préexistence technique de l’interface graphique ou de l’architecture client-serveur, la réponse semble claire : aucune de ces deux techniques n’a devancé ou présidé l’émergence de l’autre. L’explosion de l’architecture client-serveur à la fin des années 80 est l’aboutissement naturel du développement des réseaux locaux, alors que l’interface graphique est certainement l’aboutissement naturel du mode caractère ! Les deux phénomènes sont parfaitement conjoints et totalement indépendants (ce qui a certainement facilité leur évolution harmonieuse).

    L’architecture initiale de gestion des données entre une application PC et le SGBD, était le mode " file-server ". A chaque requête, la totalité du fichier transitait sur le réseau. Par exemple, même dans le cas d’une requête dont le résultat n’était qu’une seule colonne d’une table en contenant un million, ce million d’enregistrements se promenait entre le serveur de fichier et le poste demandeur. En mode client-serveur, il devint possible de lancer une requête et de rapatrier uniquement les données utilement sélectionnées. Ce mode soulage donc considérablement l’usage de la bande passante et représente le premier des grands principes architecturaux qui président à l’organisation d’un réseau efficace. Techniquement cela implique qu’une partie des traitements soit effectuée sur le serveur par le SGBD.

    Ce fut le premier allégement du client et, paradoxalement, pour l’architecture distribuée, son premier pas vers la recentralisation des traitements dont elle avait voulu s’affranchir.

    Actuellement, la mode " économie d’architecture " joue " back to the future " et nous propose, sous l’étiquette NC, le retour au terminal classique. Cette tentative pernicieuse a pour unique objet de limiter les effets de notre incompétence organisationnelle à administrer correctement une vraie informatique distribuée. Le " fat " client est nécessaire, et rien n’arrêtera cette évolution, pas même le Net. En effet, malgré les apparences, les nouveaux applicatifs sont composés d’objets ActiveX ou Java Bean. Ces éléments deviennent de plus en plus lourds et doivent être stockés dans de gigantesques caches sur les postes clients pour ne pas imposer des téléchargements à chaque utilisation. Une politique d’usage deviendra rapidement indispensable.

    Les principes classiques de la répartition entre serveur et poste client sont simples ; au Canada dès le milieu des années 80 tous les administrateurs de réseaux les respectaient :

    Postulat 1 : tout ce qui est changeant ou partageable est accessible par tous sur un serveur (les données, les applications nouvelles ou utilisées exceptionnellement).

    Postulat 2 : tout ce qui est figé pour un temps (certaines extractions de données historiques) et/ou fréquemment utilisé (les applications régulières, la bureautique) est installé automatiquement ou rapatrié occasionnellement sur le poste client (ou sur un serveur de proximité).

    En pratique, le réseau véhicule uniquement ce qu’il est indispensable de faire circuler. D’autre part, un serveur actuel n’est pas forcément plus puissant qu’un poste client. Pourquoi alors lui demander de réaliser le travail applicatif de plusieurs centaines de ceux-ci et en plus de gérer l’ensemble des données partageables ?

    En France, un conservatisme certain dans la manière d’autoriser les personnalisations de l’interface et la répartition de l’information est à la base d’une déviation dans l’organisation et l’usage du réseau local. Lequel se limite alors à remplacer le mainframe par un " WanTel " sans en améliorer la philosophie d’usage.

    La recherche du client léger est plus un problème d’architecture que d’interface. Elle résulte simultanément d’une vision à court terme de l’économie, de l’organisation et d’une incompréhension du défi technologique que représente le Net (IntraNet, ExtraNet, InterNet).

    L’arrivée de navigateurs tels que Netscape ou Internet Explorer ont fait croire en première réflexion qu’ils étaient suffisants pour proposer à l’utilisateur un client universel ouvert à toutes les applications. Dans la réalité, HTML (ou même DHTML) facilite la navigation mais ne permet pas grand-chose au-delà d’une rudimentaire mise en page de textes ou d’images (sauf à incruster dans des scripts complexes les objets basiques de l’interface Windows). Cette vision réductrice de la complexité applicative se heurte aujourd’hui à deux réalités en convergence : les besoins du transactionnel évolué et ceux du multimédia.

    Toutes les solutions actuelles s’enchevêtrent et sont en réalité le reflet de nos errements en matière de management du système d’information et de son intendance (administration de matériels et d’applications). La vraie révolution en ce qui concerne l’architecture applicative est sans conteste la répartition sur plusieurs couches de services (N-Tiers). Elle est basée sur l’emploi généralisé d’objets techniques. Elle ouvre la voie d’une réflexion plus profonde sur la généralisation des objets " de métier ". En effet, la couche application se situe entre la couche présentation et celle gérant l’accès aux données. Cette architecture isole naturellement les processus propres au métier de l’organisation. La technique brute rejoint alors le rêve de l’organisateur et du théoricien en reconnaissant la raison d’être pratique des trois axes de modélisation (statique, dynamique, fonctionnel) et en offrant de plus l’universalité théorique de la présentation .

    Quant au futur des technologies ActiveX ou Java Bean, je laisse à d’autres la gloire de la prophétie, car il n ‘est pas forcément raisonnable d’analyser le passé pour tenter de prévoir l’avenir. Pourtant, à toutes époques, des prophètes ont tenté de prédire le futur. Dans le domaine informatique leur champ d’action se limite heureusement à la technologie. Je n’ai rien contre ces apôtres du changement, mais beaucoup parlent de tout et de rien pour paraître donner une opinion " avisée " sur chacune des technologies émergentes. Avis dont on change comme de chemise lorsque l’opportunité poussée par la réalité s’en fait sentir. C’est ainsi que l’on peut lire sous la plume d’un même auteur, mais à quelques mois d’intervalle : oui Java est mûr pour la production de masse et non Java n’est pas encore l’outil universel et stable que l’on attendait. Ou bien : Linux peut concurrencer NT et le terminal X remplacer avantageusement la philosophie Microsoft. Bonne chance aux chefs de projets !

    Les conseilleurs ne sont pas les payeurs. Que le client s’y retrouve ! Seul le présent est un futur immédiat dont le risque mérite d’être envisagé : quelles architectures et quelles techniques employer immédiatement pour satisfaire les utilisateurs et rencontrer les objectifs d’un projet sous contraintes (et lesquels ne le sont pas ?). Cela peut sembler simpliste et fastidieux mais c’est en fait le seul moyen de garantir une relative sécurité. Oui pour le rythme du changement ; non pour la cacophonie technologique !

    Le dernier défi de l’informaticien n’est plus le processeur ou le système d’exploitation, il se situe dans le pragmatisme de la méthode et des outils à utiliser pour livrer sous contraintes des applications stratégiques.

    La suite de ce chapitre s’applique uniquement au graphique sous Windows. D’ailleurs en existe-t-il économiquement un autre ? Sans les atouts natifs de ce système maintenant universel, le mode graphique, en ce qui concerne les applications de gestion, aurait plus d’inconvénients que d’avantages.

    De simples facilités comme les " copier-coller " et les " glisser-déposer " ont révolutionné la manipulation de l’information. Mais l’essentiel se situe dans la parfaite intégration des solutions complémentaires offertes par plusieurs centaines d’éditeurs indépendants.

    Pour comprendre l’incroyable puissance globale de cette solution, il faut considérer entre autres :

  • la facilité des échanges de données entre applications (un cauchemar avant Windows) ;
  • l’intégration des multiples documents par l’intermédiaire des liens OLE ;
  • l’automatisation des processus de manipulation inter-applications et de personnalisation par VBA (Visual Basic pour Applications) ;
  • l’incidence de la standardisation sur les temps de formation et sur la courbe d’utilisation réelle des fonctionnalités des produits.
  • L’intérêt de ces finesses n’est malheureusement pas évident pour ceux qui n’ont pas l’usage concret et la pratique de l’ensemble des outils périphériques à Windows. Mais pour la secrétaire ou le cadre inspiré, la source de satisfaction en termes de qualité et d’efficacité n’est pas discutable. La plupart de ces facilités sont à l’origine issues de la bureautique communicante, mais l’exigence de productivité impose désormais d’en disposer aussi dans toutes les autres applications, que ce soient des progiciels, des ERP, des outils de " supply chain " ou de développements spécifiques.

    Le problème du coût réel et du retour sur investissement d’une application graphique se trouve alors posé [Clark 1997]. Le gestionnaire et l’informaticien prennent brusquement conscience d’une série de phénomènes dont la conjonction conduit le plus souvent à l’échec du projet de développement.

    Parmi ceux-ci :

  • Le mirage de la simplicité de Windows a pour contrepartie un accroissement de la complexité des développements professionnels.
  • L'impact positif de la technologie sur les temps de développement est absorbé par la complexité des interfaces (couleur, position, choix d’objets, finesse de cadrage, etc.) et surtout par la richesse fonctionnelle des applications.
  • Les temps de réponse peuvent être décuplés par un mode graphique inadapté ou insuffisamment optimisé.
  • L’approche classique (ou systémique) de réflexion dont la préoccupation privilégiait la conception, puis l’organisation, se trouve bousculée par la réactivité inhérente aux applications graphiques.
  • Les solutions des nouveaux applicatifs sont de plus en plus souvent liées aux technologies et évoluent avec les exigences en cours de projet.
  • Les contraintes et le  stratégique imposent la nécessité de " concevoir en vue de modifications ".
  • Les techniques de modélisation formelle (liées à l’objet) ne peuvent plus être évitées et imposent la rigueur en trois axes : statique (données / métier de base), dynamique (flux / organisation circonstancielle), fonctionnel (traitements / évolution immédiate).
  • La conception et la réalisation se recouvrent et fusionnent techniquement, cela impose un profil unique d’informaticien de développement.
  • Le mode événementiel propre à Windows entraîne une structure d’application différente de celle requise par la linéarité habituelle du mode caractère.
  • L’utilisation d’objets complexes susceptibles d’apparaître ou de disparaître, de changer d’aspect ou de dimension ainsi que les nouvelles formes de manipulation de données (glisser-déposer) interdisent le maquettage et imposent un prototype représentant l’application réelle dans un état intermédiaire de développement.
  • L’architecture Client-Serveur est progressivement remplacée par le multicouches (N-tier) qui requiert de nouvelles connaissances et de nouveaux outils.
  • L’interface IHM de type Windows mute vers l’interface de type Net (DHTML, ActiveX / Java bean). Durant cette transition, les standards ergonomiques deviennent momentanément mouvants, et l’informaticien doit composer, improviser, optimiser.
  • Les développeurs doivent avant de coder disposer d’une charte graphique acceptée et surtout d’un modèle de transaction basé sur le principe d’un automate à état fini (le principe de la boucle interne de Windows). C’est pour avoir négligé ces étapes que certains projets se situent entre le sérieux retard et la dérive catastrophique.
  • Les principes de l’interface graphique et de l’événementiel remettent totalement en question les impératifs de la documentation technique.
  • Les techniques de planification, de modélisation et de coordination de projet classiques vont à l’encontre des nouvelles contraintes de réalisation (time-boxing, target-costing).
  • La visibilité des gestionnaires en regard de l’avancement réel de l’application doit être accrue afin que le risque de dérapage puisse être limité.
  • La maîtrise de la qualité du développement doit être garantie. Elle concerne simultanément la qualité technique et la qualité fonctionnelle. Elle est négociée en fonction de contraintes techniques et économiques.
  • La participation active et soutenue de la maîtrise d’ouvrage et des utilisateurs devient impérative. Une négociation encadrée par un spécialiste de la communication est indispensable pour contenir l’explosion de la demande. Elle se base sur la valeur ajoutée qui conditionne le retour sur investissement.
  • Devant de telles difficultés, de nombreux déçus des développements spécifiques se tournent alors brutalement vers les progiciels. Il est normal d’en arriver là. Le spécifique n’a plus sa raison d’être pour assurer la paie, la comptabilité, la facturation, pour gérer les stocks et, d’une manière générale, pour assurer la production. Continuer dans ces domaines à ignorer les progiciels intégrés, ERP et autres outils de " supply chain " serait une erreur grave.

    Les systèmes opérationnels lourds produits en interne sont trop coûteux et manquent souvent de qualité. Par contre, imaginer qu’ilsoit possible de généraliser cette approche à l’ensemble du système d’information de toutes les entreprises, fait abstraction de la nouvelle dimension stratégique des SI (figure 1). Dans ce champ d’application, le développement spécifique n’est pas mort. En fait, il va enfin acquérir sa réelle importance (figure 7).

    Il faut du spécifique à la fois souple et puissant pour assurer la permanente évolution d’une différenciation concurrentielle, du spécifique extrême pourrait-on dire.

     

    Le décisionnel subit des contraintes similaires dans les organisations soumises à des choix stratégiques. La nécessité de disposer d’informations fines et pertinentes est alors vitale. Dans des entreprises mondialisées, pilotées " à vue ", c’est la spécificité, la complétude et la réactivité des SI qui feront toute la différence.

    Figure 7. — Dichotomie du développement moderne

    Dans le futur cette différenciation sera peut-être l’aboutissement d’outils génériques, mais rien n’est sûr et nous en sommes très loin techniquement. Pour l’heure, la compréhension de l’usage à faire de ces systèmes et l’ordonnancement de leur réalisation, nécessitent des visionnaires bien plus que des gestionnaires. Dans certaines entreprises, la crainte de l’échec immédiat condamne irrémédiablement la performance future. Le gestionnaire choisit d’achever la boucle qui, du mainframe au client léger, ramène à une informatique centralisée. Cette solution de facilité va à l’encontre du management par la qualité totale de service (MTQS) et de la réactivité concurrentielle.

    Dans les organisations les plus conscientes des changements indispensables au futur immédiat, la révolution de l’utilisateur est en marche. S’appuyant sur la décomposition permise par l’architecture multicouches, la maîtrise d’ouvrage prototype elle-même la couche présentation et s’approprie ainsi son avenir " graphique " [Boehm 1998].

    Tout, dans ces multiples défis, conduit à une remise en cause des méthodes et plus largement de l’organisation des développements. Il faut simultanément innover dans l’ingénierie d’organisation (CMM, SPICE), dans les méthodologies de conduite de projet (RAD) ainsi que dans le choix de méthodes et de techniques de conception-réalisation adaptées à chaque application (Flux, UML, etc.).

    Comparons la souplesse et l'efficacité d'un écran de saisie de données en mode caractère avec ce que l'on peut obtenir de fonctionnellement identique sous Windows. Cette analyse ne favorise généralement pas l'interface graphique pas plus que son coûts de possession (figure 8).

    Si on évalue le coût de la puissance minimum de l'ordinateur nécessaire à une utilisation professionnelle des deux interfaces, une question sérieuse est soulevée. Afficher ou saisir de l'information sous Windows n'est pas en soit le but ultime de l'organisation. D'ailleurs, la création des données opérationnelles et l'utilisation qui en est faite dans un système d'aide à la décision sont deux aspects qu'il est vital de dissocier lors du développement d'une application.

    Figure 8. — Coûts du client-serveur / Windows (D. Martin)

    Pour saisir l'avantage réel de Windows dans la manipulation des données corporatives, il faut admettre le postulat suivant : " La perfection d'un système d'information réside dans sa capacité de rendre totalement disponible l'information " Cette facilité s'exprime à travers des applications simples à utiliser.

    Pour obtenir une performance optimale, il est impératif d'utiliser plusieurs outils de bureautique communicante en complément d’un outil de développement de type " client-serveur sous Windows ". L’ensemble permet d'accéder simplement aux données, sans programmation et sans expert, puis de les restituer dans un contexte connu de l’utilisateur. Le choix du produit n'a pas d'importance significative sur le fond. La plupart des outils de développements sont identiques dans leurs fonctions, la différence réside le plus souvent dans le facteur prix et dans la lourdeur d'utilisation.

    A cette comparaison, les outils les plus légers se qualifient presque toujours comme les meilleurs. Car, si obtenir une simple liste ou une étiquette, nécessite des outils de plusieurs milliers de francs et plusieurs minutes du plus puissant des micros disponibles, il y a de quoi désespérer l'utilisateur et le gestionnaire.

    Le passage obligé vers le Client-Serveur conduit les informaticiens à optimiser sans relâche l'architecture, les outils, et les méthodes pour s'adapter à la demande mouvante des utilisateurs. Le grand défi du pilote de projet RAD consiste aussi à organiser, avant la migration intégrale, la coexistence entre les anciennes et futures applications. D'où les difficultés inhérentes à ce type de choix : les multiples éléments qui composent un applicatif se renforcent ou s'affaiblissent en interagissant. Cet empilement de couches est le contraire de la stabilité : " Devoir gérer une instabilité technique permanente pendant le projet mais aussi en exploitation est la principale leçon à tirer d'un passage au Client-Serveur. "

     

    Client-Serveur de deuxième génération

    SQL ingénierie et l'Institut Prometheus se sont associés pour définir dix critères d'appartenance à la deuxième génération d'outils client-serveur.

  • Permettre le développement fonctionnel de l'application indépendamment des systèmes cibles (principe de la fenêtre unique).
  • Développement orienté " services " pour permettre les partitions et l’équilibrage de charge lors du découpage de l'application.
  • Support des contraintes liées aux applications transactionnelles lourdes.
  • Support d'un interface graphique et exploitation de toutes ses particularités lors du développement.
  • Support des fonctions avancées des serveurs du marché, moniteurs transactionnels ou SGBDR.
  • Reconnaissance des standards en matière de connectivité (middleware).
  • Référentiel homogène servant de base à la gestion et au développement des projets.
  • Gestion des mécanismes automatiques assurant la persistance des objets applicatifs distribués.
  • Facilité de déploiement (installation, configuration).,
  • Ouverture fonctionnelle et adaptation au cycle de vie des applicatifs.
  • Ainsi se déclinent les impératifs du client-serveur de deuxième génération, qui représente le défi des grands développements RAD du futur immédiat.

    Intégration technologique et réingénierie " projet "

    Le Client-Serveur est avant tout la victoire de la standardisation des matériels et de leur indépendance relative.

    On constate en France un marché hétéroclite de solutions et d'annonces de nouveaux produits sous les plates-formes les plus hétérogènes dans un bouillonnement aussi créatif qu'économiquement incohérent. Pendant ce temps, en Amérique du nord, les entreprises élaguent, simplifient, pour profiter de la reprise avec, " en mains ", les cartes de la rentabilité.

    Le Client-Serveur a pour seule raison d'être la disponibilité totale de l'information corporative. Cela s'effectue à travers des applications communicantes aussi conviviales et économiques que sophistiquées en termes de possibilités. Seule la panoplie Windows permet de répondre à ces critères, et Microsoft ne cache pas sa philosophie d'imposer, pour quelques dollars, les fondations du futur de l'environnement client-serveur : il sera homogène et indépendant du matériel. Pour ce qui est du logiciel, que ceux qui considèrent que Windows n'est pas un système ouvert s'interrogent sur le nombre des applications disponibles et leurs origines.

    Beaucoup n'apprécieront pas cette simplification, particulièrement ceux qui investissent et développent de l'expertise sur les grands systèmes, les minis, les Unix et autres produits lourds. Le Client-Serveur ne les condamne pas globalement et immédiatement, mais leur fin à moyen terme est inscrite dans le code de Windows. Tous voudront s'inscrire dans le courant porteur du Client-Serveur, et beaucoup déjà s'en réclament, essayant de faire rimer leurs offres avec le mot magique. Pour l'entreprise, la tâche se complique, les technologies à maîtriser se multiplient et la nécessité de faire appel à de nouvelles qualifications est un problème majeur.

    En Europe, l'emphase est mise sur l'hétérogénéité des matériels et des réseaux, il suffit pour le comprendre de lire des magazines comme Le Monde Informatique, 01 Informatique ou Logiciels & Services ; il y a pléthore de propositions. En Amérique du Nord les entreprises sont infiniment plus nombreuses et les marchés très concurrentiels, néanmoins, depuis deux ou trois années, un consensus s'est dégagé. Pour en comprendre le sens il faut avoir vécu sept années de récession et la dynamique de restructuration forcée qui en découle.

    Maintenant l'intégration totale est réalisée de facto. Pour s'en convaincre il faut analyser régulièrement les revues traitant des SGBD et des réseaux. La synthèse de ces différentes sources d'informations est la suivante : l'architecture sera Client-Serveur. Le matériel sera micros pour les postes clients et la majorité des serveurs (multiprocesseurs, tolérance de pannes). Pour les réseaux, ce sera Ethernet avec évolution vers les hauts débits et Microsoft oblige, Windows NT finira par l'emporter. En matière de SGBD Oracle résistera à SQL Serveur qui sera mieux intégré aux autres applicatifs de Microsoft propulsés par une mise en marché agressive.

    Sur les postes clients, en matière de développement, les dés sont déjà jetés. La douzaine des plus grands experts américains, unanimes pour une fois, couronnent Visual Basic ; Visual Basic langage de développement pour 90 % des applications de gestion ; Visual Basic comme langage de macros dans toutes les applications de Bureautique, de gestion de projet, de CAD/CAM, de PAO, etc. ; Visual Basic dans des outils de gestion de bases de données comme MS Access, dans les " front-end SQL " comme PowerBuilder, et autres " tools ". Et bientôt émergera l'offre Visual Basic Objet intégré à la nouvelle génération de SGBDRO. Ajoutez la facilité de l'ActiveX pour l'utilisateur final, et tout est dit, c'est simple, économique, puissant et rassurant.


    Bibliographie RAD, Conduite de projet

    Martin James, Rapid Application Development, Macmillan, 1991.

    Vickoff Jean-Pierre, RAD - Développement Rapide d’Applications, Méthodes et outils, les règles à respecter dans le développement d’application client-serveur, MGI, 1995, puis Macmillan, 1996.

    Vickoff Jean-Pierre, REENGINEERING, Vite fait bien fait, Le Paradigme du futur immédiat, QI, 1998.

    Vickoff Jean-Pierre, Réingénierie du développement d’application, Méthodes, processus, techniques et pratiques de conduite de projet sous contraintes, Gartner Group, 1999.

    Boehm B. & Bose P. A Collaborative Spiral Software Process Model, USC, 1994

    Bouchy S. L'Ingénierie des systèmes d'information évolutifs, Eyrolles, 1994

    Clark B. The Effects of software process maturity on software development effort, USC, 1997

    Englewood C. JAD the Group Session, Approach to system design, Prentice Hall, 1991.

    Egyed A. & Boehm B. Telecooperation Experience with the WinWin System, USC, 1998

    Henry A. & Monkam-Daverat L. Rédiger les procédures de l’entreprise, Les Éditions d’organisation, 1995.

    Mc Carty J. 54 Règles d'or pour un grand logiciel, Microsoft Press, 1997.

    McConnell S. Stratégie de développement rapide, Microsoft Press, 1996.

    Panet G. & Letouche R. Merise 2, modèles et techniques Merise avancés, Les Éditions d'organisation, 1994.

    Yourdon E. Modern Structured Analysis, Englewood Cliffs, 1989.



    www.RAD.fr ® © Jean-Pierre Vickoff