Nos observations sur les technologies de l'information nous ont conduit en 2004 à placer le retour de la préoccupation de la qualité informatique parmi les tous premiers thèmes de notre baromètre des préoccupations. Ce n'est évidemment pas la médiatisation en 2004 de plusieurs grandes pannes informatiques en France et à l'étranger qui pourrait tempérer cette tendance de fond.

La plupart des approches répertoriées qui visent à l'amélioration de qualité informatique, sont presque toutes nées dans les années 80. Il s'agit notamment d'ISO 9000 révisée en 2000 ; d'ITIL, le référentiel d'origine britannique de bonnes pratiques de gestion des infrastructures et du help desk ; ou encore de CMM révisé en CMMI, le modèle d'origine américaine d'évaluation de la maturité d'un centre de développement logiciel, plébiscité dans les développements offshores.

Ainsi la qualité des développements, de la gestion des infrastructures et, d'une manière plus générale des services rendus par l'informatique aux utilisateurs voire aux clients finals, est remise à l'ordre du jour et progresse de nouveau.

Toutefois un aspect de l'informatique reste jusqu'ici très en retrait des efforts d'amélioration. Il s'agit bien sûr de la définition des besoins, où la règle reste encore trop souvent le crayon, la gomme et l'expérience du rédacteur. Qui peut démontrer la cohérence d'un document de plusieurs dizaines de milliers voire de millions de mots ? Et surtout, comment arriver à ne pas incorporer dans l'expression des besoins, même malgré soi, des orientations quant aux choix techniques à prendre ?

Si l'informatique technique, militaire ou embarquée a progressé malgré tout dans ce domaine difficile, les systèmes d'information de gestion sont restés totalement étrangers à une quelconque amélioration de la méthodologie et des outils, laissant, par le fait, la coopération maîtrise d'ouvrage/maîtrise d'œuvre à la merci des aléas et des contraintes.

Une discipline du génie logiciel cherche à émerger en informatique de gestion, afin de contribuer à l'amélioration de ce point noir historique : il s'agit du Requirements Engineering. Jusqu'ici cette discipline restait cantonnée aux grands principes, ou à une méthodologie et un outillage permettant la modification plus ou moins dynamique et plus ou moins propre d'exigences (Requirements) déjà identifiées et formalisées.

Dans un pays où l'on rechigne à s'en remettre aux méthodes de co-conception telles que les méthodes agiles (qui ne sont pas sans poser par ailleurs d'autres problèmes), l'émergence de méthodologies et d'outils permettant de s'attaquer à la formalisation des besoins de manière dissociée de toute esquisse de solution en se focalisant sur les objectifs poursuivis par les initiateurs des projets est une excellente nouvelle qu'on n'attendait d'ailleurs plus.

Enfin quand on apprend qu'on dispose en Europe, une fois n'est pas coutume, d'un véritable centre d'excellence, en l'occurrence autour des travaux de l'Université Catholique de Louvain (Belgique), on se demande comment résister plus longtemps à connaître une telle discipline.

Naturellement, il ne s'agit pas d'une quelconque panacée universelle. Pour autant, il s'agit probablement d'un des plus gros effets de levier actuellement disponible dans le domaine. En effet, les progrès que l'on peut espérer dans l'industrialisation de la fabrication du code ou dans la maîtrise des infrastructures sont nécessairement limités tellement les investissements consentis y ont été importants depuis maintenant vingt ans.

En revanche l'expression des besoins comme la validation du logiciel, constitue un domaine qui souffre d'un tel retard que la moindre amélioration doit mécaniquement produire sur la qualité globale un effet important. Il s'agit d'un gisement de qualité à fort rendement. Comment l'ignorer ?