Quand on parle de modernisation, on parle généralement d’intégration, de réutilisation, de technologies hétérogènes, donc de naviguer dans des zones rarement bien connues. Les technologies sont souvent nombreuses et non compatibles au premier abord. Pour ces raisons, la preuve de concept joue un rôle particulièrement critique dans ce genre de projet.

Comme je le disais dans un article sur “Quand doit-on commencer à parler de technologie“, la majorité des technologies sont en mesure de faire le travail. Par contre il faut s’assurer d’utiliser la bonne technologie dans le bon rôle afin de minimiser les risques et diminuer les coûts.

À ce titre, la preuve de concept est un outil très intéressant à plusieurs niveaux car elle permet de :

• minimiser les risques technologiques
• raffiner l’estimation et l’échéancier
• établir un premier contact pour l’équipe technique en formation
• présenter aux décideurs un aspect plus concret de la solution à mettre en place.

Pour atteindre ces précieux objectifs, la preuve de concept doit être significative. Par exemple, dans le cadre d’un projet de site transactionnel financier, une preuve de concept qui consiste à développer une page web qui accède un base de donnée est parfaitement inutile.

Pour être efficace, une preuve de concept doit :

• Résoudre les principales incertitudes technologiques
• Être réalisée par ceux qui développeront l’application
• Être déployée dans un environnement technologique représentatif
• Avoir un envergure réaliste
• Être réalisée le plus tôt possible en début de projet
• Être composée d’un aspect “Visuel”
• Disposer d’un budget raisonnable

Il est complexe de réunir ces éléments car certains semblent en contradiction. Comment peut-on connaître les principales incertitudes technologiques en début de projet ???? Comment ceux qui développeront l’application et qui généralement doivent être formés, peuvent-ils être ceux qui réaliseront la preuve de concept ????

Il n’y a pas de solution miracle. Un choix doit être effectué selon le contexte du projet afin d’optimiser l’ensemble des caractéristiques idéales de la preuve de concept. De plus, il n’est pas interdit de faire plus d’une preuve de concept. Les incertitudes majeures sont souvent identifiables rapidement. Ils seront donc solutionnées dans une première preuve de concept. Si, pendant le cours du projet, d’autres incertitudes apparaissent, une autre preuve de concept pourrait devenir profitable. En fait, l’équipe de développement devrait avoir le réflexe d’utiliser la preuve de concept dès qu’une incertitude peut avoir un impact important sur le projet afin d’éviter d’emprunter des orientations erronnées et très coûteuses.

Il s’agit donc en début de projet de bien doser les différents éléments pour en arriver à la meilleure preuve de concept possible, avec comme objectif minimum d’éliminer à tout le moins les “impossibilités”.

Dans le cadre d’un projet de modernisation, l’absence d’une preuve de concept “significative” peut devenir un facteur d’échec autant au niveau des technologies en jeu qu’au niveau des budgets et des échéanciers. Par exemple, des estimations qui seront basées sur une mauvaise preuve de concept mettront dès lors le projet dans une position délicate.

J’indique dans la liste des caractéristiques d’une bonne preuve de concept qu’elle doit comporter un aspect visuel. C’est donc dire qu’une preuve de concept uniquement composée de “code” convaincra les technologues mais sera sans grands effets sur les gestionnaires et les décideurs. Étant donnée que ce sont eux qui payent…… ne les oubliez pas.