Conclusion
Développement rapide d’applications

Dans les grandes entreprises, il est nécessaire d’aller de plus en plus vite pour offrir aux utilisateurs les outils dont ils ont un besoin vital. De même, la mise en production d’une application développée « entre informaticiens » n’est plus concevable : les risques de rejet pur et simple par les utilisateurs de l’application produite sont trop importants. Il s’agit de trouver un moyen de développer des applications selon une méthodologie permettant de répondre à ces besoins cruciaux pour l’entreprise : il faut aller vite (un marché se gagne plus facilement quand l’entreprise y est présente rapidement et efficacement) ; il faut produire des logiciels correspondant exactement aux besoins des utilisateurs ; il faut enfin garantir une réactivité importante face aux évolutions des marchés concurrentiels.

La remise en cause de la méthode employée pour produire les logiciels de l’entreprise est une obligation. Les méthodes « anciennes », trop linéaires et souvent « mal » appliquées, qui amènent à produire une documentation volumineuse, redondante, jamais à jour et que de toutes façons « personne ne lit vraiment », ne répondent pas à ces nouveaux besoins. Il est alors tentant d’examiner de nouvelles solutions. Comme souvent, celles-ci sont nées de l’autre côté de l’Atlantique. Le développement rapide d’applications (Rapid Application Development ou RAD) est une réponse possible. Inventée par l’Américain James Martin, cette méthode offre des avantages importants :

• la forte implication des futurs utilisateurs de l’application permet de garantir l’adéquation entre les besoins exprimés et le logiciel produit ;

• la logique économique qu’elle implique interdit le développement de fonctionnalités « inutiles » ;

• l’utilisation judicieuse des outils informatiques disponibles oriente vers la production d’une documentation nécessaire et suffisante ;

• le respect strict de l’enveloppe budgétaire et des délais permet d’avoir une vision stratégique efficace.

Le principe fondamental du RAD est le suivant : il s’agit de fixer, dès l’initialisation du projet, une enveloppe temps/argent dans laquelle le projet doit impérativement s’inscrire. Le projet étant construit intégralement avec les utilisateurs, c’est à eux, avec l’aide d’un animateur RAD, qu’incombe la tâche de faire cadrer le projet avec le budget défini. L’ensemble des phases du projet est couvert par le RAD et réalisé avec les futurs utilisateurs du système : de la phase de conception de la base de données jusqu’à la mise au point des écrans et des états produits, par itérations successives de prototypage. Il en résulte alors l’obligation de ne développer que des fonctionnalités « utiles », en éliminant les développements particuliers n’emportant pas l’adhésion générale. Il est souvent demandé par des utilisateurs des versions multiples d’une restitution (qu’elle soit imprimable ou consultable à l’écran) : dans le cas d’un projet RAD, on cherche à produire une restitution unique, rassemblant l’ensemble des informations et permettant d’emporter les suffrages de chacun des participants au projet.

Le RAD ne permet pas de traiter des projets dont la charge prévisible est trop importante (supérieure à trois années/homme). Dans ce cas, un lotissement est nécessaire afin de découper le projet en autant de sous-projets compatibles avec les exigences de la méthode. Il est en effet extrêmement délicat d’animer des réunions RAD mettant en cause un trop grand nombre d’utilisateurs différents sur un même projet (les risques de « dérive » des réunions sont alors importants).

Si le RAD a été d’abord conçu pour mener des projets de type transactionnel (permettant à une entreprise d’acquérir de nouvelles données grâce à des fonctionnalités de saisie et de mise à jour), d’autres types d’applications peuvent également s’inspirer largement de la méthode pour gagner en efficacité. La mise en place d’un système informatique décisionnel nécessite la même implication importante des utilisateurs afin de garantir l’adéquation exacte du produit livré aux besoins à couvrir.