Documenter vos applications informatiques pour éviter le désastre

Et qu’arrivera-t-il demain ?

Qu’il s’agisse d’une petite PME en croissance, ou d’une entreprise de plus grande taille, aucun collaborateur du service IT n’est éternel (ni des autres services d’ailleurs).
Tôt ou tard il s’arrêtera, il partira.
Peut-être a-t-il mis au point des applications qui organisent votre entreprise, des programmes qui permettent à la production de fonctionner comme aujourd’hui ?
Ou a-t-il codé des formules complexes qui elles aussi vous donnent entièrement satisfaction.

Et toute société évolue, se restructure, change ses process.
Toute application est ponctuée de mises à jour, mineures ou majeures.
Parfois pour corriger des bugs, parfois pour de subtiles améliorations, ou pour des nouvelles versions totalement innovantes.

Et qu’arrivera-t-il quand le concepteur de ces développements IT qui vous ont permis de grandir partira ?
Comment fera son successeur pour comprendre ce qui existe, se l’approprier, et à nouveau faire évoluer votre entreprise ?

Si rien n’a été documenté et que votre activité utilise l’informatique… vous avez un sérieux problème.

Qui peut même aller jusqu’à la fermeture de votre société.

Vous me direz : “avec les outils de développement actuels, il est possible de disposer de toute la documentation nécessaire”.
L’avez-vous testé ?
Avez-vous tenté d’éditer la “documentation automatique” d’une de vos applications et de la donner pour avis à un autre informaticien, qui ne connaît pas votre dossier ?
Non ?
Faites le test.
Vous aurez vite compris !

J’ai également entendu dire que tous les informaticiens qui “codent” ont pour habitude de mettre des commentaires dans leurs sources.
Là aussi, prenez un peu de temps, et tentez de lire ces commentaires. Vous serez très surpris.

Il en va de même pour les “sociétés de services” qui mettent à disposition des développeurs chez un client.
Étant en charge du dossier, ce développeur connaît mieux l’application que le client lui-même.
Et si vous avez plusieurs développeurs en mission, chacun se charge d’une partie différente de son collègue.
Si un seul de ces développeurs vous quitte, là aussi vous avez un sérieux problème avec votre client.
Car remplacer une personne par une autre, c’est très courant.

Le transfert de compétence, si rien n’a été documenté, est toujours un échec cuisant.

Ce genre de situation est, malheureusement, très courante.
Il m’est arrivé de conseiller à des patrons de PME de permettre à leur service informatique de documenter leurs développements… et d’essuyer un refus catégorique : trop cher, pas utile, personne n’est irremplaçable, etc…

Des patrons qui réagissent comme cela démontrent une incapacité à totale a perdurer. La fermeture n’est pas loin.

Et pourtant !

Et pourtant, avec un minimum d’organisation, un minimum d’investissement, ces sociétés seraient à l’abri d’un désastre annoncé.

Sans rentrer dans le détail, il est important de travailler sur deux niveaux.

Le premier niveau – L’application de manière générale !

Toute application à mettre en œuvre impose toujours une analyse globale de la part du service informatique, ou de la société de service avec laquelle vous travaillez.
Elle est nécessaire pour connaître la faisabilité du projet, avoir une idée de sa complexité, de son timing, de son budget.
Malheureusement, certains adeptes de la méthode “Agile” (qui, de manière simplifiée, consiste à travailler par petites étapes totalement séparées, qui ne dépassent que rarement un mois) oublient qu’avant de se lancer dans un “sprint” (une étape), il faut avoir analysé la demande dans son ensemble.

Cette analyse est précieuse et il est de votre devoir, en tant que patron, de la conserver. Elle reprend le pourquoi et le comment du projet.
Et très souvent, des schémas très clairs qui permettraient à tout nouvel informaticien de se faire une idée d’ensemble de ce qui a été mis en place.

Si vous disposez d’une gestion documentaire, ou d’un système de classement informatique (accessible à vos collaborateurs), c’est le moment de tout centraliser et d’organiser cela par application. Même Google Drive peut suffire.
Créez-y des dossiers, et sous-dossiers. Déposez-y les analyses. C’est comme cela que vous débuterez à mettre en place votre premier niveau de connaissances.

Demandez également, à la personne qui effectue les analyses IT, d’ajouter dans ces dossiers d’autres schémas, des “flowcharts” (diagrammes de flux) qui expliquent de manière générique chaque sous-étape d’un projet.

Prenons un exemple : vous souhaitez faire développer une application qui gère les retours clients. Gérer ce que le client vous retourne pour une quelconque raison:  car la taille ne convient pas ou la couleur n’est pas la bonne.
L’analyse globale sera un document qui explique le projet, qui détaille (en général de manière exhaustive) les causes possibles de retours, qui prévoit pour chaque cause un traitement spécifique.

Les flux que vous pouvez ajouter dans votre dossier de documentation pourraient représenter le chemin que suivra la marchandise qui vous est retournée, et ce qu’il y a lieu de faire :

• Vérification de la marchandise retournée
• Le client a-t-il droit à un échange ou un remboursement
• Ssi le client n’y a pas droit, envoi d’un email lui expliquant pourquoi et lui demander que faire de son produit retourné
• S’il y a droit, souhaite-t-il un autre article (par exemple une autre couleur), ou un remboursement ?
• Si remboursement…
• Etc.

Et croyez-moi, un tel flowchart est facile à réaliser et très précieux.
Ci-dessous, un exemple de flowchart.
Copyright de cet exemple:  Edraw Software

Il va de soi que si une application qui tourne depuis 2 ans doit évoluer, si on ajoute une étape, un cas de remboursement… il faut conjointement mettre à jour ce flowchart.

Un conseil : ne changez jamais un document existant par un nouveau qui reprend les modifications apportées.
Travaillez toujours par “version”. Le document original… vous le conservez. La première évolution … est une copié modifiée du premier, mais à laquelle vous donnez un autre nom. Par exemple : “Flux Retour Marchandise” pour l’original, et “Flux Retour Marchandise – V2” pour le second.
Et si possible, le premier point de cette nouvelle version résume ce qui est différent par rapport à l’original, et le pourquoi du changement.

Si vous réussissez déjà à imposer ce genre de documentation et de classement, vous êtes à 60% de votre travail.

Le second niveau – Le code du programme

Qu’il s’agisse de PHP, de C++, de Java, de Windev, etc… tous les langages informatiques permettent d’intégrer des lignes de description dans le code écrit par les développeurs.

De nombreux d’entre eux ont l’habitude de “documenter” leur code.
Mais pas tous !

Il est de votre devoir d’imposer quelques règles à tout développeur (interne ou externe) qui crée ou modifie le code de vos applications.

Ces règles peuvent être complexes, ce n’est pas nécessaire. Vous pourrez vous en sortir avec quelques règles assez simples :

• N’autorisez qu’une seule langue pour les descriptions ajoutées dans le code. En général, ce sera l’anglais.
  Car imaginez que votre développeur rédige ses commentaires explicatifs en Néerlandais (sans que vous le sachiez) et qu’après vous décidez de sous-traiter le projet à une société française !
  Vous aurez bien des surprises.
• Imposez aux développeurs de décrire les champs et éléments marquants du programme, au début du code : par exemple les paramètres d’entrée, les variables globales, les paramètres de sortie, etc.
• Dans le corps même du programme, chaque “fonction” se doit d’être expliquée.
  Exemple (dans ce cas je vous l’explique en français au lieu de l’anglais habituel): Les lignes ci-dessous recherchent la date d’achat du produit retourné, et mettent la variable “Retour_Ok” à “VRAI” si date d’achat de moins de 30 jours et sinon à “FAUX”

Vous voyez, ce n’est pas très compliqué.

Et comme déjà signalé, la majorité des bons développeurs s’adonnent toujours à ces documentations de codes.
Pour en avoir le cœur net, n’hésitez pas à demander de temps en temps à ce que votre développeur vous montre ce qu’il écrit.
Vous ne devez avoir aucune connaissance spécifique pour cet exercice.
Mais devriez retrouver facilement ces lignes de commentaires et vous rendre compte de leur lisibilité fonctionnelle.

Croire qu’il n’est pas nécessaire pour une société de documenter ses développements informatiques (et maintenir cette documentation) est la preuve de l’inaptitude d’un dirigeant d’entreprise.

Oui, cela demande d’y consacrer un peu de temps, une part infime de votre budget informatique.
Oui, cela demande une organisation pour stocker et gérer ces documents, pour les mettre à disposition des personnes concernées.
Mais là aussi, même de simples outils comme ceux de Google peuvent répondre aux besoins.
Je puis vous assurer que je ne travaille pas pour Google, mais il faut reconnaître que ces outils “gratuits” sont suffisamment efficaces pour mémoriser la documentation, la classer, y donner accès, créer des flowchart, etc.

A la lecture de cet article, certains d’entre vous pourraient considérer ces remarques comme dépassées.
En se disant qu’il n’est pas possible qu’à l’heure actuelle, une société ne se soucie nullement de ces principes de base.

Détrompez-vous. Ces “patrons” décrits ici existent bel et bien.
Et dans les PME, ils sont très nombreux, trop nombreux.