Le Savoir faire

En utilisant vos différents logiciels d'entreprises, vous est peut-être déjà venu à l'idée que certaines solutions proposées ou développées par votre partenaire manquaient de cohérence ou de fluidité ? Que leurs prise en main par un nouveau collaborateur s'avérait complexe ou encore que vous faisiez fasse à des comportements assez aléatoires qui provoquent des variations de performance ou parfois des résultats inexpliqués ?

Il existe une manière simple de savoir :

Plusieurs indices majeurs permettent en effet de suspecter facilement la qualité perfectible l'un logiciel :

Une interface graphique incohérente ressemblant à un adolescent en pleine crise de poussée d'acné juvénile : des boutons partout situés aléatoirement aux 4 coins des fenêtres, 100% modales où aucun écran ne peut s'ouvrir conjointement sans devoir fermer celui en cours
Des performances s’effondrent au fur et à mesure de la montée de charge de la solution : du nombre d’utilisateurs concurrents, de la taille des documents ou du volume des données, au fil des années...
Des nouvelles fonctionnalités qui trainent à voir le jour, la mise en conformité avec de nouvelles technologies qui posent de gros problèmes, des bugs jamais résolus ou résolus qui réapparaissent et des couts d’adaptations qui s’envolent

Si vous suspectez qu'une de vos solutions rentre dans cette catégorie, j'ai le regret de vous vous annoncer que vous venez seulement de découvrir la partie visible de l'iceberg et que ce que vous découvriez si vous pouviez avoir accès et comprendre le code s'apparente certainement à une véritable usine à gaz...

Cette situation signifie en langage "développement" que votre logiciel n'est aucunement "standardisé" et ne dispose pas d'architecture ni couche "d'abstraction" comme expliqué plus loin mais que ses différentes fonctionnalités ont été développées à l'emporte-pièce, sans aucune cohérence et le plus souvent à l'aide de code dupliqué, très difficile à maitriser et à faire évoluer. Une manière de faire découlant d'une analyse "séquentielle" résolument "ancestrale" puisque datant des années 90, mais qui ne permet plus de faire face aux besoins en terme de taille, fonctionnalités, performances et évolutivités des solutions actuelles

Il existe actuellement deux familles de méthodologies dédiées à la conception de logiciels : celles d'organisations telles que World-Wide Institute of Software Architects (WWISA) qui comparent les projets de conception de logiciels aux projets de constructions de génie civil, et les méthodes agiles, comme l'extrème programming qui ne se fondent pas sur la définition exhaustive et précoce des besoins mais bien ensemble de règles strictes, sur la souplesse et la mise en valeur du "capital humain", d’où l’importance du savoir faire.

La complexité des solutions actuelles étant, tout comme les besoins qui évoluent collatéralement avec la technologie, il devient très délicat et surtout couteux d’établir une analyse complète des spécifications avant de débuter un projet ( en sachant que beaucoup ne connaissant pas leurs besoins exacts ), sans compter que durant la période de conception les besoins risquent d’évoluer, voir de changer rendant l'analyse obsolète ce qui remet fortement en question ce type d’approche : un ouvrage change rarement de forme durant sa construction, un logiciel presque toujours…

les méthodes agiles ( voir eXtrème Programming ) semblent donc bien plus appropriées aux technologies actuelles et à conception de logiciel modernes, mais encore faut-il qu’elle soient utilisées à bon escient car du « concept Agile » à « Programmation sauvage », il n’y a souvent qu’un tout petit pas mais la qualité du résultat final s’en trouve fortement impacté !

Un logiciel en effet, tout comme un bâtiment, doit être doté d’une architecture interne, la particularité est qu’elle se doit d’être robuste pour assurer la stabilité et l’efficacité de la solution mais aussi très souple afin de pouvoir facilement s’adapter aux nouveaux besoins et garantir son évolutivité, architecture qui pourrait se comparer à un système antisismique dans le génie civil, à la fois flexible et résistante... les choses ne sont donc pas si simples que certains ne vous de prétendent.

Pour être efficace, un logiciel doit donc posséder plusieurs caractéristiques fondamentales :

Une interface homogène et standardisée garantissant une prise en main rapide et une utilisation efficace de la solution ( types d'écrans standardisés devant être clairement identifiables, la compréhension d'un d'écran doit induire spontanément la compréhension des autres)

Une architecture en couches modulaires qui induit une structure rigoureuse et évolutive rendant totalement indépendant le code dédié au fonctionnement des modules métiers et de la communication avec les données ( cette couche assure donc "l'abstraction" du fonctionnement du logiciel vis-à-vis de l'interface homme / machine et des données )

Des règles de codages strictes et éprouvées garantissant l'homogénéité et l’unicité du code qui assure la fiabilité, la sécurité et l'évolutivité de la solution ( la modification ou un dysfonctionnement d'un module ne peut alors qu'impacter une seule partie du code sans pouvoir interférer avec un autre )

Voilà donc ce qu'il faut faire pour disposer d'un logiciel intuitif, fiable et performant qui pourra évoluer en fonction de vos futurs défis et de l'avancement de la technologie. Car le développement de logiciels et de solutions informatiques reste une question de maîtrise, de savoir faire mais aussi de talent. encore faut il bien choisir son outil et son environnement, ce que vous pouvez découvrir dans les pages suivantes : A propos de l'outil