L’informatique des grandes entreprises.

Dans le monde des grandes entreprises, il est totalement inconcevable de débuter un nouveau projet informatique sans passer par une série de phases telles que l’analyse détaillée, les spécifications de base, l’architecture, la conception, l’implémentation, les tests approfondis, l’installation et le déploiement.

Et s’il s’agit d’un projet lié à un site internet ou à une boutique e-commerce, ces étapes seront complétées par une étude du design des pages web, de l’ergonomie de fonctionnement, du respect de la charte graphique, et de la compatibilité des navigateurs.

Pourquoi tant d’étapes ? Pourquoi s’obliger un tel parcours ?

Tout simplement car ces sociétés ont compris qu’il s’agit là du seul et unique moyen de réaliser un projet fiable aux coûts les plus bas, et le plus adapté à recevoir des évolutions ultérieures.

Un exemple loufoque.

Pour ne prendre qu’un exemple, imaginons qu’un dirigeant d’une marque automobile se décide à lancer un nouveau modèle en contactant directement l’atelier, leur demandant de se mettre au travail sans tarder.
Sans aucun plan, sans être au préalable passé par l’étape “ingénieurs”, “design”, “motorisation”, “transport”, etc.
A peine un châssis sera-t-il créé qu’il faudra le modifier car ne convient pas aux ancrages du moteur.
Puis le remodifier à nouveau car l’allonger serait plus adapté aux 5 portes, puis encore modifié car un modèle SUV est plus tendance, etc.

Vous pensez que j’exagère ?
Et avez très certainement raison…pour ce qui concerne le monde des grandes entreprises.
Plus aucune n’oserait se risquer à débuter un nouveau projet sans une analyse précise reprenant les différents passages obligés.

Mais pourquoi le schéma de travail serait-il différent pour une PME ?

Tout simplement car sans une analyse précise, l’estimation de la complexité du projet et de son planning sont toujours sous-estimés.
L’informaticien prétend pouvoir mener à bien le projet en proposant des délais irréalistes, qui coûteraient moins chers à la PME.

Mais ces délais ne seront jamais tenus.

Pire, le développement sera bancal, totalement instable, fera apparaître très rapidement des “effets de bord”, des erreurs dans d’autres parties de votre système d’information.
Il sera alors nécessaire de revenir dans le code, le modifier et le remodifier durant des jours, des semaines, des mois.
En définitive, après des délais qui auront explosés, des coûts qui atteindront des sommets, vous vous retrouverez avec une “usine à gaz”, une application incertaine, impossible à faire encore évoluer, mais que vous accepterez néanmoins car vous avez pris la responsabilité du choix de cette solution.

Si l’on représente ce type de développement hasardeux sur une ligne de temps, pour un projet prévu sur deux mois, on peut le représenter comme ci-dessous.
Avec les nombreuses réunions qui annoncent des changements dans le projet, des nombreuses phases de corrections des développements déjà réalisés pour s’adapter aux changements demandés.

Un projet qui devait durer 2 mois, en prendra 8 à 10, et accouchera d’une base de données mal pensée, limitée, d’un design approximatif, d’un codage complexe, illisible et peu propice à de futures évolutions.

En optant pour la solution de facilité, qui semble la plus rapide et la moins onéreuse, en omettant une analyse sérieuse, la PME va au-devant de surcoûts inévitables, de délais multipliés par 4 ou par 5, et d’une solution qui ne tiendra pas 2 ou 3 ans. Qu’il faudra recommencer de A à Z.

L’analyse d’un projet n’est pas un investissement démesuré.

Bien souvent, lorsqu’il faut intervenir pour réparer les dégâts, le patron de PME précise que s’il a choisi cette solution “de facilité”, c’était car sa petite société n’est pas à comparer avec une multinationale, et qu’une “analyse” semblait être réservée aux grandes entreprises, qu’elle lui est impayable, que cela prend trop de temps.

Et c’est là qu’est l’erreur. Le terme “Analyse” représente aussi bien l’étude globale faite pour un projet important d’une grosse société, que pour un travail plus réduit, plus adapté aux PME. Il fait peur aux PME.
Il n’est nul besoin de passer des semaines et des semaines d’analyse pour réussir un projet informatique, pour mettre toutes les chances de son côté, avoir la garantie que le travail sera effectué dans les temps, et répondre à la demande.

Le projet IT en 8 étapes.

Quelles sont les phases et conseils que l’on peut mettre en avant pour votre nouveau projet  ?

1) Réunion initiale.

La première chose est de débuter par une réunion qui accueillera tant le patron de la PME, que l’utilisateur final de ce projet. Cela peut être un responsable commercial, un magasinier, ou 2 à 3 “clients” que vous connaissez bien s’il s’agit d’un projet qui impactera vos clients (boutique e-commerce par exemple).
Durant cette réunion, la demande sera expliquée, cadrée, limitée.
Ce que l’on attend, mais aussi ce que l’on ne veut pas.
Bien sûr, on ne pensera pas à tout lors de cette première réunion, c’est normal. L’important est de débuter et de formaliser cela par un petit rapport de quelques pages qui sera transmis à tous les participants.

2) Pré-analyse.

La seconde phase revient à l’informaticien.
Il va imaginer une solution, tant au niveau du design de la base de données (tables utilisées, dépendances, champs, contrôles, etc.), que des écrans qui serviront aux utilisateurs. Cette seconde étape, selon l’amplitude du projet, peut varier fortement.
Mais bien souvent, dans le monde des PME, on se situera entre 2 et 10 jours.

3) Réunion de présentation.

La 3ème étape est une nouvelle réunion, avec les mêmes interlocuteurs. S’il s’agit d’un projet “web”, la présence du graphiste lié à la société est intéressante afin qu’il puisse donner son avis et prendre part à la discussion. L’informaticien propose sa solution et attend les réactions.
A ce niveau, ce que l’on attend des personnes présentes n’est pas de proposer un revirement total, mais simplement des remarques, des améliorations qui peuvent s’intégrer au projet, le rendre plus convivial, plus adapté à l’utilisateur final.

4) Formalisation.

Vient ensuite la formalisation finale faite par l’informaticien en tenant compte des remarques, et avec l’aide (éventuelle) du graphiste.
Tout cela va très vite. De un à 3 jours semble une bonne fourchette.

5) Réunion de confirmation.

La dernière réunion ne sert plus qu’à avaliser ce qui se trouve sur le document papier.
Celui-ci reprendra le résumé de la demande initiale, le schéma simplifié de la base de données (pour information), une maquette de chaque écran qui sera développé avec les couleurs, l’emplacement des logos, des champs, des boutons, etc.

Si des rapports sont prévus par le projet (listes, graphiques, etc.), leur maquette doit également être jointe au document proposé.

Ici encore, plus question de modification majeure.
S’il y a des remarques, elles doivent être intégrables sans devoir repasser par une étape d’analyse + réunion.

Toute modification souhaitée qui ne serait pas implémentable facilement fera l’objet d’une évolution future du programme.

6) Le développement.

Nous arrivons enfin dans la phase de développement réel. L’informaticien s’en charge parfois, ou sous-traite cela à une autre personne, un autre partenaire. Le document qui a été avalisé par tous sera la “bible” de l’écriture du code.
Durant cette phase, il est totalement proscrit que de nouvelles demandes proviennent de la PME pour modifier le projet.

Car changer la donne en cours de développement est la pire erreur à ne pas commettre.
Cela “tuerait” votre projet.

7) La phase de tests.

Après la phase de développement, l’informaticien mettre son module en phase de tests.
Ce seront les utilisateurs finaux qui se chargeront de ces tests (ou une personne de la PME à même de le faire).
Ils passeront quelques heures à tester l’application, mettront sur papier leurs remarques qui seront centralisées par le développeur.

8) Les corrections.

Le développeur apportera les corrections demandées, et mettra l’application en production.

Au total, 3 réunions. Et un planning respecté.

Le plus important est de définir la demande dès le départ. De bien la cerner.

Et si vous avez oublié quelque chose ?
Bien souvent l’informaticien y pensera pour vous et la proposera d’emblée dans sa première formalisation.

Le plus dangereux, changer la demande en cours de développement.

Si vous respectez ces quelques règles, très schématisées, il y a de fortes probabilités que votre projet soit mené à bien dans les délais, dans le budget annoncé, et qu’il sera ensuite évoluer sainement car la base de donne aura été bien conçue, l’ergonomie bien pensée.

Vous avez TOUT à y gagner.