Notre expérience dans les expertises et les audits nous permet de répondre à toutes sortes de problématiques.

Par exemple, dernièrement, nous a été confié un mandat d’évaluation d’un logiciel métier développé en complément d’un ERP installé. Ce logiciel, composé de nombreux modules, a été fait par un collaborateur d’une entreprise industrielle, au début pour ses propres besoins, puis mis à disposition d’autres utilisatrices/utilisateurs.

Ayant dirigé plusieurs équipes de développement de logiciel nous savons ce qu’il en est de la partie commentaires du code et de la constitution d’un dossier technique. Il y a toujours des prétextes innombrables à ne pas renseigner le code et le dossier technique malgré tous les outils à disposition pour faire cela correctement sans grande perte de temps.

Qu’entend-t-on (quand on entend quelque chose…) ? Pas le temps tout de suite, plus tard ; ce n’est pas la version définitive ; c’est évident, pas besoin de perdre du temps ; je n’en vois pas l’utilité ça change tout le temps ; je ne rédige pas très bien ; j’ai des problèmes avec l’orthographe ; je suis tout seul sur ce projet, je maîtrise tout ; etc.

Qu’il existe des réticences à rédiger un mode d’emploi c’est compréhensible dans la mesure où le logiciel n’est pas terminé ou qu’il est en perpétuelle mutation après installation. Par contre le dossier technique doit toujours exister et toutes les étapes et le cheminement, avec les difficultés rencontrées et les solutions aux problèmes, de l’équipe de projet ou du développeur indépendant, doivent y figurer. Il tombe sous le sens qu’un développeur doit pouvoir partir ou ne plus être en mesure de continuer son travail sans que cela ne porte préjudice aux différents projets sur lesquels cette personne travaille.

Le dossier technique doit permettre de reprendre un développement avec un minimum de questions ou même sans questions du tout, posées au développeur.

Dans le cas de cet audit il existait une application sous forme de fichiers avec un document plutôt axé utilisateurs dont un chapitre de quelques lignes traitait de la mise en œuvre : très nettement insuffisant pour un consultant qui partait d’une connaissance limitée dans le produit, exactement ce qu’il se serait passé, en vrai, si le développeur était parti rapidement sans laisser d’adresse, dans le pire des scénarios.

Nous avions prévu de tester le code, de sortir une évaluation qualitative de ce qui avait été fait, mais il n’a jamais été possible d’aller jusque-là.

Cependant l’audit s’est arrêté sur un constat implacable : il était impossible pour quelqu’un d’extérieur de faire tourner cette application dans un autre environnement que celui de production. Impossible car le dossier technique était très incomplet pour ne pas dire inexistant. En outre comment évaluer un logiciel lorsque le développeur continue sans arrêt de travailler dessus sans mettre à notre disposition les fichiers modifiés ?

C’est aussi l’illustration d’un mandat de départ qui consistait à qualifier le développement lui-même et qui s’est finalement orienté vers le constat qu’il était impossible de migrer cette application, par conséquent une sérieuse remise en cause du programmeur doit lui permettre de corriger les lacunes rencontrées et notamment de constituer le plus rapidement possible le dossier technique dont nous ne cessons de mettre en avant l’importance.

Besoin d'un audit ou d'une expertise ?