On aimerait que la construction d’une application informatique suive des règles similaires à celles de la construction d’un bâtiment.
Celui qui fait office d’architecte, disons la « MOA » dessinerait les plans d’une application. Dûment validés par le client, ils seraient conformes à ses attentes. Remis aux développeurs ils correspondraient à la réalité de ce qui a été développé. Mais hélas les choses ne se passent jamais ainsi.
D’abord, contrairement au bâtiment, une application est immatérielle. Autant le client de l’architecte peut se faire une idée claire de ce que sera sa future maison à la seule vue des plans, autant il est difficile pour une MOA de donner la même visibilité au donneur d’ordre. C’est la raison pour laquelle le cycle en V a été délaissé au profit des pratiques agiles. Les spécifications générales et détaillées du cycle en V si exhaustives et précises soient-elles ne garantissait pas que l’application obtenue corresponde aux besoins des utilisateurs en général et du marché en particulier. Les méthodes itératives sont venues corriger cela en introduisant la construction par étapes successives. Ainsi la MOA et son donneur d’ordre peuvent intervenir pour corriger le tir.
Ces pratiques ont d’indéniables avantages mais elles ont aussi quelques angles morts qui grippent la démarche de transformation numérique.
Le test
Le premier angle mort est celui du test qui s’inscrit difficilement dans des cycles de développement très court. Surtout lorsque la charge de test de non-régression devient importante. La raison en est que la part de tests manuel reste importante. Leur automatisation est complexe et incompatible avec la versatilité d’une application qui change tout le temps. Du fait de leur manque de fluidité les tests constituent le principal goulot d’étranglement d’un projet informatique.
La documentation
L’autre angle mort est celui de documentation. Les pratiques itératives limitent le formalisme, réduisant le nombre et l’exhaustivité des documents disponibles sur le projet. Cela n’a peut-être que peu d’importance lors de la première livraison mais cela devient critique avec le vieillissement de l’application. Cela d’autant plus que, d’une évolution à l’autre, les documents de spécification ne sont que rarement mis à jour. Que reste-t-il alors lorsque, suite à l’intervention d’une administration publique, la MOA s’inquiète de la bonne implémentation de certaines obligations réglementaires ? Rien d’autre que le souvenir des acteurs encore présents. A défaut la MOA n’a alors que deux options, soit tester l’application pour voir comment elle se comporte, soit interroger l’équipe de développement. Elle sera même parfois obligée de recourir aux deux options pour avoir des certitudes. En effet, à l’examen du code source, le développeur émettra un « ça doit marcher comme ça » que seuls des tests pourront confirmer.
Le déficit documentaire a d’autres conséquences tout aussi dommageables pour la transformation digitale. Outre qu’il noie la mémoire du projet dans le turnover, il coupe le lien entre le métier et le projet. Certes le métier est associé lors des sprints mais qu’en reste-t-il qui soit formalisé ? Quelles besoins, contraintes, exigences le métier a-t-il validé à quelle étape du projet ? Quel retour, quel suivi le métier a-t-il sur le projet dans la durée ? L’absence de réponse à ces questions introduit des zones d’incertitudes dans la gouvernance des systèmes de plus en plus nombreux, interconnectés et interdépendants.
Commentaires