Les solutions de la performance


De plus en plus fréquemment, les développements spécifiques ne se justifient plus économiquement (sauf en ce qui concerne le stratégique de différenciation). Ce constat est particulièrement évident lorsque les délais représentent un critère primordial qui complexifie le travail de l’informaticien. La recherche d'une solution " progiciel " est alors souvent envisagée sans autre forme de raisonnement quitte a sacrifier la couverture fonctionnelle à la raison économique.

Le tout progiciel ne représente pourtant pas la seule alternative au tout spécifique. Une autre possibilité permet de construire la " solution " par l'achat d’éléments (modèles, écrans, données, documentation, objets, etc.).

  • Solutions / logiciels
  • Briques logicielles / architecture distribuée

    La notion d’éléments de " solution " recouvre l'obtention de :

  • divers modèles (données, traitements),

  • scripts de création de bases de données,

  • jeux d'essais et tests de cheminements,

  • dessins d'écrans,

  • spécifications et algorithmes,

  • modules complets, parties de code,

  • composants ou objets " métier ".

  • Réaliser un développement dans ces conditions présente de nombreux avantages en termes de :

  • budget, par réduction des coûts ;

  • délai, par réduction drastique des attentes avant mise en exploitation ;

  • qualité, par suppression de la plupart des conditions d'erreurs et aménagement de la solution au plus près de nouveaux besoins ;

  • visibilité, par levée de la majorité des risques fonctionnels, techniques et de ceux liés aux contraintes de délais.

  • Un développement peut donc se réaliser économiquement à partir d'une combinaison de trois options :

  • achat d'un progiciel,

  • développement spécifique,

  • achat de solutions.

  • De plus, une telle ingénierie représente souvent le choix optimal en termes de réduction des risques (fonctionnel, technique, économique).

    En fonction du problème, des solutions possibles et de l'environnement, le choix de la solution optimale peut, pragmatiquement, s'effectuer à trois moments décisifs de la vie du projet :

  • à la fin de l'étape d'immersion de l'animateur dans le domaine fonctionnel, si une solution progiciel couvrant la totalité des exigences d'un périmètre fonctionnel figé est évidente ;

  • à la fin de la phase de Cadrage, lorsque les exigences du système cible sont définies et qu'une solution spécifique est écartée pour des raisons de coûts, de délais ou de ressources ;

  • à la fin de la phase de Design (dans les cas complexes), lorsque la modélisation des traitements, des données et des communications permet de comparer les solutions dans le détail de leurs avantages et inconvénients respectifs.


  • Figure 1 — Problématique " organisationnelle " du pilote de projet

    L’ensemble des orientations possibles :

  • choix de développement,
  • achats de solutions ou de composants,
  • couche d’externalisation,
  • pilotage d’une action d’amélioration continue de la qualité,
  • opération de réingénierie des procédés du " métier ",
  • doit être réexaminé à chaque jalon majeur du projet (figure 1).


  • www.RAD.fr ® © Jean-Pierre Vickoff