Comment débuter le développement d'une application de gestion ?

Le syndrome de la page blanche

Vous voilà enfin prêt : vous savez écrire des pages PHP, manipuler des classes, générer des commandes SQL, dessiner de beaux schémas UML. Et maintenant, il faut écrire une application... Par où commencer ? Faut-il s'occuper de la base de données ? Choisir un framework ? Réaliser une belle analyse UML, et si oui, comment l'aborder ?

Bref, pas évident de se mettre en route... Pas de panique, nous allons dérouler les différentes étapes, et essayer d'éviter les pièges les plus classiques !

Première étape : analyser les besoins

On développe rarement pour rien (quoique...) : il vaut mieux que notre travail serve à quelque chose. La première étape consiste à cerner le besoin du demandeur.

Vous risquez d'avoir un cahier des charges qui, parfois, fera 2 lignes (si elles sont écrites!). Le plus facile, c'est de commencer à réaliser des diagrammes de cas d'utilisation. Ils vont vous permettre d'identifier d'une part les différents intervenants (très important pour la gestion des droits, par la suite), et d'autre part les différentes briques dont vous aurez besoin.

Vous créerez autant de schémas que vous aurez de « volets » dans votre application. Dernièrement, j'ai réalisé une application qui a trois usages :

    • d'une part, elle permet de qualifier les communes par rapport à une procédure administrative ;
    • d'autre part, et c'est le cœur de celle-ci, elle gère des dossiers administratifs, qui aboutissent à la génération de courriers au format ODT, qui sont envoyés aux administrés ;
    • et enfin, pour des besoins de contrôle, un module d'import de données issues d'un autre service a été rajouté, accompagné d'une interface de consultation.

Dans cet exemple, nous avons eu donc trois schémas de cas d'utilisation, chaque schéma pouvant posséder plusieurs cas ; par exemple, le dernier schéma comprenait un cas concernant l'import des données, et un cas pour la consultation.

Chaque cas doit être documenté : il ne suffit pas de faire un joli schéma, encore faut-il dire à quoi il sert. Et là, seul le recours au français, c'est à dire à la rédaction de ce que doit faire chaque cas, comment il fonctionne, à qui il est destiné, etc. vous permettra d'être assez précis.

Dans les schémas, n'oubliez pas d'indiquer les différents types d'intervenants : ils vous permettront de préparer la matrice des droits d'accès (tout le monde n'a pas forcément accès à tout).

Le document que vous allez produire est destiné principalement au demandeur de l'application : comme les schémas sont assez simples, et les cas documentés, ils doit être compréhensible par toute personne concernée par le projet. Le demandeur va pouvoir ainsi valider votre vision des choses et, le cas échéant, vous apporter des précisions complémentaires. Il est plus facile de commenter un texte existant que de partir de zéro : tout le monde n'est pas écrivain !

Vous pouvez compléter ce document par une petite analyse technique, par exemple un calcul rapide de la taille de la base de données, ou une estimation des ressources physiques nécessaires (si 10 personnes doivent utiliser le logiciel, ce n'est pas tout à fait la même chose que 10 000 connexions simultanées, en terme de dimensionnement de la plate-forme technique). Vous pouvez également mettre en garde par rapport à des demandes certes légitimes, mais qui peuvent être coûteuses à développer : si on vous demande de réaliser une application de saisie sur le terrain qui doit fonctionner en mode déconnecté sur des terminaux de différents systèmes d'exploitation (IOS, ANDROID, etc.), il est probable que le coût ou le temps de développement total sera plus important qu'on aurait pu le penser initialement. Vous préparez ainsi la phase suivante : la définition des priorités.

Deuxième étape : définir les priorités

Maintenant que vous avez un aperçu de l'application à réaliser, vous allez pouvoir définir, avec le demandeur, les cas d'utilisation qu'il semble pertinent de faire en priorité. Demandez également au demandeur s'il a des exigences calendaires fortes (pour éviter la réponse du type : c'est pour demain matin, alors que la saisie ne doit commencer effectivement que dans trois mois), et sur quels cas d'utilisation elles portent.

Définissez également avec le demandeur les différentes versions à produire. Même si vous livrez chaque semaine un module différent, cela ne fait pas une version : il faut, à un moment donné, fournir un ensemble fonctionnel. Avec une livraison de versions successives, vous permettrez au demandeur de tester au fur et à mesure et, au besoin, de commencer à travailler en attendant que la suite arrive.

Ainsi, vous allez pouvoir organiser le déroulement du développement dans le temps.

Troisième étape : fixer un rythme de développement

Il y a quelques années de cela, quand j'attaquais une application, je commençais par faire une analyse pendant plusieurs jours ou semaines, puis passais à la base de données, et enfin au codage. J'ai eu des stagiaires qui, grâce à cette approche, finissait leur stage sans rien avoir produit de fonctionnel : dommage...

Aujourd'hui, les méthodes dites « agiles » permettent d'appréhender le développement de façon beaucoup plus efficace. Si vous êtes intégré au sein d'une équipe de développeurs, avec de la chance, vous travaillerez selon la méthode Scrum (http://fr.wikipedia.org/wiki/Scrum_(m%C3%A9thode)). Si vous êtes tout seul, ce qui est mon cas (et probablement le votre aussi), mettre en place une méthode Scrum ne rime pas à grand chose. Par contre, vous pouvez en retenir certains points, qui me paraissent essentiels :

    • définissez des cycles de développement courts (1 à 3 semaines). Au bout du cycle, vous devez avoir fini quelque chose (écriture d'un module, définition de la plate-forme technique en tout début de développement – nous y reviendrons – , écriture d'un module, etc.). Vous devez être capables de montrer quelque chose qui fonctionne au demandeur (ou lui expliquer ce que vous avez mis en place pendant le cycle si rien n'est montrable) ;
    • à la fin du cycle, définissez (si vous le pouvez) le contenu du cycle suivant avec le demandeur (après lui avoir montré ce que vous avez fait pendant le cycle précédent). Il est probable que le schéma initialement défini évolue, le contraire serait étonnant !
    • Ne vous laissez pas « distraire » pendant un cycle : vous avez décidé (en commun avec le demandeur) de vous attaquer à un module, finissez-le. Si on vous demande de vous attaquer à autre chose, faites comprendre que c'est plus judicieux d'attendre le cycle suivant (d'où l'intérêt de cycles courts). Vous y gagnerez de la tranquillité d'esprit, et cela n'en sera que plus profitable à votre travail ;
    • en cas de difficulté, ne vous entêtez pas. D'abord, allez vous coucher : je ne compte plus le nombre de fois où la solution, cherchée des heures la veille, était évidente le lendemain matin... Ensuite, demandez de l'aide : il n'y a pas de honte à ne pas savoir résoudre un problème, et des yeux extérieurs permettent souvent de détecter des erreurs qu'on a devant soi (la fameuse poutre qu'on a dans l'œil) !
    • Dans le même ordre d'idée, vous travaillez pour vivre, et pas l'inverse. Ne cherchez pas le « burn out » (surmenage, en français), vous n'y gagnerez strictement rien... Les week-ends et les soirées sont à vous, pas à votre employeur ;
    • sélectionnez des outils adaptés à votre travail ; j'y reviendrai plus tard ;
    • codez proprement, en mettant des commentaires (n'oubliez pas les commentaires qui permettent les générations automatiques de documentation – en PHP ou Java, ils commencent par /**). Par contre, ne perdez pas de temps à décrire par le détail, dans un document à part, ce que vous faites : personne ne le lira.

Voilà, on a fait le tour. Votre application va se monter petit à petit, et vous aurez la fierté de la présenter aux utilisateurs au fur et à mesure que les différentes versions seront mises en production !

Bon, c'est vrai, il faut qu'on rentre maintenant dans le détail du codage...