Pour des logiciels de qualité qui répondent aux besoins

Pour des logiciels de qualité qui répondent aux besoins des communes
Stéphan Geulette - Avril 2008
Régulièrement, des communes acquièrent ou font développer de nouvelles applications
informatiques en vue de faciliter l'accomplissement de leurs missions. Mais comment
juger de la qualité et de l'adéquation d'un logiciel? Dans tous les cas, un test par les
utilisateurs finaux s'impose.
L’adéquation aux besoins et le bon fonctionnement des logiciels utilisés au sein de
l'administration sont importants pour que les agents puissent remplir leurs tâches avec
succès. Hélas, on rencontre souvent tantôt des logiciels qui fonctionnent mal ou qui sont
obsolètes, tantôt des logiciels achetés qui ne sont pas utilisés car ne répondant pas
vraiment aux besoins des utilisateurs, tantôt des logiciels qui ne s’intègrent pas
correctement parmi les logiciels déjà présents.
L’adéquation
Le choix d'un logiciel devrait idéalement se faire, en grande partie, après que les
personnes qui devront l’utiliser l’aient testé. On peut s’interroger sur un fournisseur qui
ne voudrait pas mettre à disposition un espace de test pour un futur client. Car l'achat
d'un outil informatique devant répondre aux besoins particuliers de la commune ne
peut pas se faire sur catalogue. L'informaticien communal devra également juger de la
bonne intégration du logiciel dans le parc existant ainsi que de l'interopérabilité possible
avec les logiciels existants.
Les agents communaux possèdent, chacun dans leur domaine, les compétences
nécessaires pour tester et juger une application informatique dédiée à leur domaine. Si
cette dernière leur paraît vraiment trop compliquée, c'est qu'elle n’est pas bien adaptée à
leurs besoins. Dès lors, il y a de fortes chances qu'ils ne l’utiliseront pas correctement,
voire pas du tout. Contacter des utilisateurs d’autres communes qui ont déjà une
expérience avec un logiciel permet également d’avoir un avis complémentaire intéressant
qui sera donné avec plus de recul.
Si un logiciel déjà existant peut être testé, il n’en est pas de même pour un logiciel qui
doit être développé. Comment s’assurer, dans ce cas, de la qualité future de celui-ci, qui
n’est souvent évaluée a posteriori par le "commanditaire" qu’à travers les problèmes qui
apparaissent et/ou subsistent lors de son utilisation, et donc à un moment où il est trop
tard pour commencer à penser à une démarche "qualité".
La qualité
Qu’entend-on par la qualité d’un logiciel ? Elle englobe des notions variées qui
concernent:
- l’utilisation du logiciel: répondre aux fonctionnalités demandées, avoir un usage facile
dans une interface simple, proposer une aide (intégrée ou dans une documentation), …;
- le cœur du logiciel: sa conception et sa structure modulaires, la lisibilité du code
source, la documentation du code source, l’adaptabilité, … Autant d’éléments
nécessaires pour assurer une évolution des fonctionnalités et une reprise éventuelle du
développement par d’autres personnes que le développeur original;
- le comportement du logiciel: ses bonnes performances, fiabilité et sécurité.
La bonne qualité d’un logiciel dépend de ces 3 notions qui ont toutes la même
importance. En effet, on pourrait croire que la qualité de conception du cœur du logiciel
a moins d’importance que sa qualité d’utilisation mais c’est essentiellement la qualité de
conception qui va le plus influencer la "maintenabilité" et l’évolutivité du logiciel, et
donc sa qualité d’utilisation future. Le développement d’un logiciel ne se termine pas
lorsque la première version est utilisée. On considère en général que l’effort de
développement en maintenance du logiciel est aussi important - si pas plus - que l’effort
de développement initial.
La méthodologie de travail
L’assurance d’une bonne qualité de logiciel tient essentiellement dans les méthodologies
utilisées lors de la phase de conception et de maintenance. Ces méthodologies peuvent
être utilisées aussi bien pour un développement en interne à l’administration que pour un
développement réalisé par une société. Dans ce dernier cas, la commune peut
développement réalisé par une société. Dans ce dernier cas, la commune peut
renseigner dans son cahier des charges l’utilisation de ces méthodes de travail afin de
s’assurer d’une longue vie pour son logiciel.
La phase d’analyse et de conception la plus rencontrée dans les faits se présente comme
suit: une analyse exhaustive est réalisée, elle est suivie par une phase de développement
complet du logiciel, qui est enfin présenté aux utilisateurs pour qu’ils le testent.
L’inconvénient de cette méthodologie est que l’utilisateur final ne peut donner son avis
sur le logiciel qu’en fin de phase de développement. Cela pose problème car l’utilisateur,
face à un outil concret, demande à juste titre des modifications ou des améliorations pour
que celui-ci soit adapté à ses besoins ou à sa façon de travailler. Ces modifications posent
parfois de gros problèmes aux développeurs qui doivent éventuellement repenser de
manière profonde le logiciel. Cette phase de modification n’a en général pas été
suffisamment prise en compte dans les délais initiaux, ce qui provoque des retards et un
travail dans l’urgence.
Les méthodes de développement dites "agiles" permettent de pallier à ces
inconvénients. L’idée est, en effet, de faire succéder à intervalles réguliers (par ex. 2 à 3
semaines) des courtes phases d’analyse, de conception et de test avec les utilisateurs. Les
utilisateurs participent donc à la conception du logiciel tout au long de la phase de
développement, ce qui leur donne le sentiment positif de construire le logiciel et favorise
l’innovation. Les méthodes de développement agiles intègrent très souvent une
méthodologie de tests écrits parallèlement au logiciel.
Les tests unitaires consistent à écrire, pour chaque fonctionnalité du logiciel, un test
correspondant servant à tester la fonctionnalité écrite. Ces tests unitaires peuvent être
complétés par d’autres types de tests (fonctionnels, performance, …). A tout moment, il
est possible de lancer la batterie de tests automatiques afin de vérifier que les dernières
modifications faites dans le code source n’ont pas impacté le logiciel. Certaines
méthodes agiles prônent même de commencer par écrire le test unitaire d’une nouvelle
fonctionnalité avant de l’implémenter dans le code source. Cette méthodologie facilite
grandement le travail de maintenance du code source et sa reprise par un autre
développeur.
Le travail en communauté a l’avantage de permettre la relecture du code source par
d’autres développeurs. Plus le nombre de développeurs relisant le code source est
important, moins le logiciel comportera de failles de programmation et plus son code
source sera techniquement de qualité. Ce travail en communauté n’est pas exclusivement
réservé aux projets Open Source. Certaines grosses sociétés informatiques fonctionnent
suivant ce même principe. Cependant, dans la grande majorité des cas, les sociétés
privées n’ont pas les ressources nécessaires pour le faire et le développement d’une
application est souvent confié à une ou deux personnes seulement.
Le travail en communauté a aussi l’avantage de rendre la solution plus pérenne étant
donné que la maîtrise du logiciel est partagée entre plusieurs personnes ou acteurs. Le
fait de travailler sous licence Open Source est un prérequis nécessaire si l’on vise à
augmenter le nombre de développeurs dans une communauté. Cela ne signifie pas
automatiquement qu’un logiciel sous licence Open Source dispose d’une communauté
importante et utilise les bonnes méthodologies de développement (raccourci qu’on a
souvent tendance à faire). Pour évaluer la future qualité d'un logiciel Open Source, il faut
donc évaluer les méthodes de développement utilisées et l'importance de la communauté.
La disponibilité du code pousse également les développeurs à peaufiner leur code
sachant qu’il sera relu et devra éventuellement être adapté par d’autres personnes.
Un outil de "versionnement" des sources permet de disposer d’une base centrale
contenant les sources d’un logiciel. Cet outil est absolument nécessaire lorsque plusieurs
développeurs travaillent sur le même code source mais peut aussi être utilisé par une
seule personne. En effet, il est très intéressant de pouvoir commenter chaque
modification réalisée dans le code, de comparer certaines versions d’une même source
ou de pouvoir facilement récupérer une version précise du logiciel. L’accès à un
historique du code facilite grandement la maintenance et la reprise du code par un autre
développeur.
Différents outils de communication permettent d’échanger, d’enregistrer et de garder un
historique des informations voyageant entre les différents acteurs d’un projet (chefs de
projet, utilisateurs, développeurs, testeurs, …). Les forums, wiki, listes de diffusion,
outils de gestion des failles ou des demandes d’évolution, et centres de documentation en
font partie.
Mais les outils de communication seuls ne suffisent évidemment pas! La volonté et
l’effort de communication dépendent évidemment des personnes qui font partie du projet.
Conclusion
Que ce soit pour le choix d’un logiciel existant ou pour le développement d’un nouvel
outil, l’adéquation de ce logiciel doit toujours être validée par les personnes qui vont
l’utiliser. Exiger d’un fournisseur de pouvoir tester correctement une application dans des
conditions réelles est un minimum pour valider le choix d'un logiciel.
La qualité d’un logiciel dépend essentiellement des méthodologies de développement
utilisées. Celles qui ont été présentées dans cet article sont plus souvent utilisées dans le
cadre des communautés Open Source que dans les sociétés qui fournissent des logiciels.
Cela s’explique par plusieurs raisons:
- les projets Open Source, de par la communauté de développeurs nombreux et dispersés,
nécessitent des méthodes strictes de travail;
- ces méthodologies sont pour la plupart issues des communautés Open Source qui, pour
la raison précitée, en avaient besoin. L’évolution de ces méthodologies est également
favorisée de par la nature de la communauté Open Source composée en partie de
chercheurs, universitaires, consultants privés, etc. On est loin de l’idée reçue "de
communautés d’étudiants barbus";
- la meilleure communication dans l’Open Source avantage également la connaissance de
ces méthodes par les développeurs;
- ces méthodologies demandent un temps initial de mise en œuvre (ce qui va à
contre-courant de la politique d’une société privée qui vise souvent à réduire les coûts),
qui est cependant compensé grâce à des temps de maintenance et de développement de
nouvelles fonctionnalités moins importants et surtout grâce à la meilleure qualité du
logiciel.
Les "indicateurs de qualité" présentés dans cet article vous aideront à mieux juger de la
qualité d’un logiciel ou à faire développer des logiciels de qualité.
***
Pour en savoir plus :
- Les méthodes agiles: http://fr.wikipedia.org/wiki/Méthode_agile
- Les tests unitaires: http://fr.wikipedia.org/wiki/Test_unitaire
- La gestion de versions des sources:
http://fr.wikipedia.org/wiki/Système_de_gestion_de_versions
Ce document, imprimé le 23-02-2017, provient du site de l'Union des Villes et Communes de Wallonie (www.uvcw.be).
Les textes, illustrations, données, bases de données, logiciels, noms, appellations commerciales et noms de domaines, marques et logos sont protégés par des droits de propriété
intellectuelles.
Plus d'informations à l'adresse www.uvcw.be/plan-du-site/disclaimer.cfm
© Union des Villes et Communes de Wallonie asbl