1. Les étapes d'un projet - aborder l'écriture d'un logiciel

A.Le développement traditionnel : le cycle en V

Le développement logiciel est mené traditionnellement selon un postulat : le demandeur (maître d'ouvrage) définit ses besoins, les décrit, et le développeur (maître d'œuvre) réalise le logiciel correspondant. Le demandeur vérifie ensuite que le logiciel correspond bien à sa demande.

Le modèle du cycle en V est basé sur deux branches : la première descend depuis l'expression du besoin vers le codage, la seconde remonte du codage vers la mise en production, en passant par les phases de tests.

B.Maîtrise d'œuvre, maîtrise d'ouvrage

Le cycle en V nécessite l'intervention de deux acteurs majeurs : le maître d'ouvrage, celui qui définit ce qu'il veut, et le maître d'œuvre,celui qui réalise l'opération.

Cette dichotomie permet de séparer parfaitement les rôles : le maître d'ouvrage écrit le cahier des charges, le maître d'œuvre réalise ce qui a été demandé. Le maître d'ouvrage « paye » après avoir vérifié que ce qui lui a été livré correspond bien à sa demande.

Cette technique a été mise au point par l'industrie, et est parfaitement adaptée à la création d'objets... réels. Par exemple, si je veux faire fabriquer un boulon, il suffit que j'en fournisse le plan, que j'en donne les dimensions, les caractéristiques du matériau à employer (dureté, résistance, couleur...), le pas de vis à employer, la profondeur des sillons, etc.

Le fabricant fournit un premier jeu : il suffit de réaliser des tests unitaires, puis de lancer une pré-série, vérifier que tout va bien, et enfin contrôler la production. En cas de litige, c'est simple : soit le boulon correspond à ce qui est demandé, et il suffit de payer le montant convenu, soit il ne correspond pas, et le fabricant ne sera pas payé.

Dans le domaine de l'écriture d'un logiciel informatique, c'est beaucoup plus compliqué... On ne crée rien de tangible : on peut voir un dessin d'écran, et subodorer que cet écran va permettre d'obtenir d'autres informations, mais c'est à peu près tout. Un logiciel n'est qu'une « vue de l'esprit », une œuvre de création intellectuelle, à tel point que deux développeurs vont très probablement créer deux programmes différents pour le même usage...

De toute force, les équipes ou sociétés informatiques essaient de mettre en place le couple maître d'ouvrage/maître d'œuvre. C'est un modèle très confortable : un cahier des charges est rédigé, et il « suffit » d'y répondre pour considérer que le travail est mené à bien.

Malheureusement, la rédaction du cahier des charges est particulièrement compliqué : il est très difficile, pour des personnes qui ne sont pas rompues à l'informatique, qui n'ont pas une connaissance globale des nouveautés, de ce qu'on peut faire, des limites (en bref, la perle rare qui, si elle existait, serait payée bien plus que les dirigeants de multinationales...), d'établir précisément ce qu'elle veulent obtenir. À contrario, un informaticien ne connaît pas le métier de l'utilisateur final, ou en a une vue très partielle. Et même s'il pense comprendre ce que veut l'utilisateur, il doit rester très modeste : ce qu'il a compris, c'est ce qu'a été capable de lui transmettre le demandeur, et ce dernier n'a probablement pas une vision globale de ce qu'il veut.

Pour aider le maître d'ouvrage, soit ce dernier est formé à l'informatique (c'est coûteux et cela l'éloigne forcément de son métier d'origine), soit on fait appel à un assistant à maîtrise d'ouvrage (soit les deux), ce qui fait qu'on fait sous-traiter à un tiers l'expression des besoins et la mise en forme.

Une fois le cahier des charges rédigé (c'est souvent un pavé indigeste qui peut représenter plusieurs centaines de pages), il reste au maître d'œuvre, tout d'abord à y répondre dans le cadre d'un appel d'offres, et ensuite à réalisé ce qui est demandé.

Attardons-nous un peu à l'appel d'offres...

Réaliser un cahier des charges nécessite une débauche d'énergie importante. Il est souvent la synthèse de plusieurs avis, des compromis sont trouvés, l'objectif étant d'obtenir le logiciel qui fera tout pour tout le monde et, bien sûr, à un coût défiant toute concurrence (rare sont les sociétés qui ont de l'argent à gaspiller).

Les sociétés qui veulent se positionner commencent par lire le cahier des charges, et identifient rapidement ce qu'elles savent faire, ce qui leur paraît réalisable, et ce qui ne sera que difficilement mis en œuvre. Elles savent également qu'elles vont s'appuyer, très souvent, sur des outils qu'elles maîtrisent (frameworks de développement, progiciels...), qui ont leurs propres limites, et qu'elles devront adapter pour essayer de répondre à la demande.

L'objectif de la société est de remporter le marché pour gagner de l'argent. Pour remporter le marché, deux arguments sont mis en avant : d'une part le prix total, et d'autre part la « complétude » de la solution proposée, c'est à dire l'engagement que prend la société en terme de réalisation. La société qui répond à l'appel d'offres va passer un certain temps à répondre point par point au cahier des charges : il faudra parfois lire entre les lignes pour s'assurer que ce qui est écrit sera effectivement réalisé.

Le maître d'œuvre sait pertinemment qu'il ne pourra pas réaliser un certain nombre de points présents dans le cahier des charges. De même, il sait qu'il aura du retard (le contraire serait étonnant). Le cahier des charges prévoit des pénalités (de retard, de non réalisation, etc.). Que pensez-vous que va faire le maître d'œuvre quand il va établir son offre financière ? Il va tout simplement intégrer les coûts des pénalités qu'il estime peu probable d'éviter...

Une fois les offres déposées, elles sont étudiées sur le plan technique. Et très souvent, la réponse qui semble la mieux positionnée sur le plan technique est également... la plus chère. Le financeur, trop souvent, décidera de prendre la solution la moins disante (techniquement et surtout financièrement), en espérant en avoir pour son argent... Pas gagné, comme pari !

Mais revenons à notre projet...

Pour formaliser le développement selon ces approches, de nombreuses méthodes ont vu le jour, dont la plus courante est la méthode CMMI (Capability Maturity Model Integration). Il existe également une norme ISO, la norme 15504, également connue sous le nom de SPICE (Software Process Improvement and Capability Determination), les deux étant amenées à converger.

C.Les inconvénients des démarches traditionnelles

Les méthodes traditionnelles sont basées sur la rédaction du cahier des charges, qui est le « juge de paix » du projet. Le maître d'œuvre doit réaliser tout ce qui est prévu, et uniquement ce qui est prévu.

Si ce mécanisme est parfait sur le papier, il présente au moins deux inconvénients. Le premier tient à la difficulté de formaliser quelque chose qui n'existe pas (le logiciel) dans sa complétude (on l'a vu dans le paragraphe précédent). Si le cahier des charges est réalisé par des personnes peu au fait de l'informatique, on pourra aboutir à des demandes aberrantes : aujourd'hui, si un client réalisait un cahier des charges pour disposer d'un véhicule capable de se déplacer dans tous les environnements (terre, air, eau, espace), pouvant transporter 5 personnes, et à une vitesse de 10000 Km/h, il est probable qu'il n'obtiendrait pas le produit désiré... À contrario, si on ne fait confiance qu'à des informaticiens, on obtiendra un produit... fait pour des informaticiens !

Le second inconvénient tient à la durée du projet. Entre l'expression des besoins et la mise en production, beaucoup de temps peut s'écouler. Hélas, pendant cette période, les besoins peuvent évoluer, la concurrence s'exacerber, de nouveaux marchés apparaître... Le cahier des charges étant par définition intangible, sauf à multiplier des avenants, le logiciel mis en production risque fort d'être dépassé quand il sera terminé.

Il est également reproché aux méthodes traditionnelles d'être très consommatrices en papier – on parle de documentation pléthorique. La mise en place d'une démarche de ce type, par exemple CMMI, entraîne de nombreuses réunions à tous les niveaux du projet, avec rédaction systématique de comptes-rendus. Les incidents sont déclarés sur papier, confirmés, traités, puis leur correction vérifiée, le plus souvent dans le cadre d'une procédure d'assurance qualité. L'état d'avancement du projet est vérifié à partir de cette documentation, et non à partir du fonctionnement proprement dit du logiciel, le paradigme étant que la documentation reflète la réalité du développement. Sur de gros projets, cette documentation va finir par être très gourmande en temps, mobiliser plusieurs personnes uniquement pour dire que le développement du logiciel suit son cours ou qu'il fonctionne...

Pour éviter ces écueils, de nouvelles méthodes sont apparues ces dernières années, les méthodes agiles.

D.Les méthodes Agiles

Face à la complexité de mise en œuvre de projets et pour limiter les risques inhérents aux démarches traditionnelles, à savoir, effet tunnel, retards de mise en œuvre, non prise en compte des besoins apparus en cours de développement, inadéquation du logiciel vis à vis des pratiques des utilisateurs..., sont apparues des méthodes basées sur des principes différents.

1.Le manifeste Agile¹

En 2001, aux États-Unis, dix-sept figures éminentes du développement logiciel se sont réunies pour débattre du thème unificateur de leurs méthodes respectives, dites méthodes agiles. Les plus connus d'entre eux étaient Ward Cunningham l'inventeur du Wiki via WikiWikiWeb, Kent Beck, père de l'extreme programming et cofondateur de JUnit, Ken Schwaber et Jeff Sutherland, fondateurs de Scrum, Jim Highsmith, prônant l'ASD, Alistair Cockburn pour la méthode Crystal clear, Martin Fowler, et Dave Thomas ainsi que Arie van Bennekum pour DSDM (Dynamic System Development Method) la version anglaise du RAD (Développement rapide d'applications). Ces 17 experts venant tous d'horizons différents réussirent à extraire de leur concepts respectifs des critères pour définir une nouvelle façon des développer des logiciels :

De cette réunion devait émerger le Manifeste Agile, considéré comme la définition canonique du développement Agile et de ses principes sous-jacents.

Le Manifeste Agile débute par la déclaration suivante :

Nous avons trouvé une voie améliorant le développement logiciel en réalisant ce travail et en aidant les autres à le faire. De ce fait nous avons déduit des valeurs communes.

Le Manifeste Agile est constitué de 4 valeurs et de 12 principes fondateurs.

a) Les 4 Valeurs

Les quatre valeurs fondamentales Agiles sont :

• L’interaction avec les personnes plutôt que les processus et les outils.
• Un produit opérationnel plutôt qu’une documentation pléthorique.
• La collaboration avec le client plutôt que la négociation de contrat.
• La réactivité face au changement plutôt que le suivi d'un plan.

b) Les 12 principes

• Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles.
• Le changement est accepté, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client.
• Livrez fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte.
• Les gens de l'art et les développeurs doivent collaborer quotidiennement au projet.
• Bâtissez le projet autour de personnes motivées. Donnez leur l'environnement et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail.
• La méthode la plus efficace de transmettre l'information est une conversation en face à face.
• Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet.
• Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment.
• Une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité.
• La simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle.
• Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'auto-organisent.
• À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens.

E.Les apports des méthodes Agiles

Les méthodes dites « agiles » s'affranchissent des contraintes inhérentes aux méthodes traditionnelles basées sur des cahiers des charges très complets et très lourds, avec rapidement des relations conflictuelles sur les délais de mise en œuvre ou la complétude fonctionnelle.

Elles sont basées sur quelques principes simples :

• un cahier des charges « minimaliste », de quelques pages maximum
• des arbitrages pour hiérarchiser les cas d'utilisation à développer en priorité
• une présence permanente du client, qui précise ses besoins et valide en temps réel ce qui doit être développé ou non
• des tests unitaires et de recette réalisés à partir de scénarios établis avant le codage, validés ensemble par les développeurs et les fonctionnels
• des livraisons par modules réduits, impliquant des cycles de développement courts (2-3 semaines maximum)
• des itérations courtes, pour faire avancer le produit, et mettre en production au fur et à mesure

Il existe plusieurs méthodes actuellement, dont les plus connues sont² SCRUM, Extreme Programming (XP), Rapid Application Developpement (RAD), Dynamic systems development method (DSDM), Adaptive software development (ASD), Feature Driven Development(FDD), Crystal clear, Processus Urbanisant les Méthodes Agiles (PUMA).

1.SCRUM

SCRUM (mélée en français) : cette méthode fournit un cadre de gestion de projet, mais pas de règles d'ingénierie logicielle. Elle peut être utilisée pour tout projet (et pas uniquement informatique), mais doit être complétée, pour les aspects techniques, par d'autres méthodes « techniques ».

Principe général :

• l'organisation est divisée en petites équipes multidisciplinaires et auto-organisées
• le travail est divisé en une liste de petits livrables concrets, dont chaque élément est trié par priorité, et dont la taille relative est estimée
• le temps est divisé en petites itérations de taille fixe (en général, 2 ou 3 semaines), appelées sprint. A l'issue de chaque sprint, une démonstration est réalisée avec un produit potentiellement livrable
• le planning de la version doit être optimisé et les priorités mises à jour avec le client, sur la base de ce qui a été appris après chaque sprint.
• Le processus est optimisé en organisant une rétrospective après chaque sprint.

Concrètement, chaque sprint démarre par une réunion qui permet de fixer les objectifs (ce qui va être réalisé pendant la durée du sprint). Chaque matin, une réunion de 10' maxi est organisée au sein de l'équipe, la mêlée (scrum). Tous les participants restent debout ! Enfin, en fin de sprint, une démo est présentée, suivie d'une réunion de rétrospective, qui permet de discuter sur ce qu'il s'est passé pendant le sprint.

Scrum, méthode de gestion du projet, est souvent associée à l'extreme programming, méthode de programmation.

2.Extreme Programming³

• Client sur site : un représentant métier accompagne en permanence l'équipe de développement
• jeu du planning, revu au début de chaque itération, en précisant les cas d'utilisation à implémenter
• intégration continue : toute modification apportée est archivée dans le référentiel, le projet est recompilé et les tests sont rejoués. A chaque étape, le projet est alors versé sur une machine de validation
• petites livraisons : pas plus de quelques semaines entre chaque livraison
• rythme soutenable : le développeur doit conserver sa vie personnelle. Pas plus de 7 à 8 heures de travail par jour
• tests de recette, écris conjointement par les développeurs et les fonctionnels à chaque itération. Ils constituent la base de validation de celle-ci (juge de paix)
• tests unitaires : chaque modification de code est soumise à des tests unitaires pour vérifier les anomalies. Ils sont écrits avant le code
• conception simple : on ne développe que ce qui est demandé, sans créer du code générique. Le développeur s'en tient à la tâche de la journée. Ne pas mélanger avec la création d'outils ou de classes génériques conçues hors projet.
• utilisation de métaphores, pour faciliter la compréhension entre les développeurs et les fonctionnels
• refactoring : les équipes remanient le code, et améliorent ses fondement sans changer ni les contrats, ni les services qu'il rend
• appropriation du code : il appartient à toute l'équipe, chacun peut le modifier pourvu que les tests réussissent
• convention de nommage : le pendant du précédent, indispensable pour que le code reste lisible. Normes et méthodes communes pour tous les objets manipulés
• programmation en binôme. Rarement appliqué, mais nécessité de conserver des relations et des échanges permanents entre les développeurs

F.Les inconvénients des méthodes agiles

Si elles présentent beaucoup d'avantages, elles ne peuvent être utilisées systématiquement dans tous les cas de figure.

sur des très gros projets, elles ne peuvent être mises en œuvre qu'à condition de segmenter les modules en une taille raisonnable ;

sur le plan réglementaire, il est très difficile de fixer des conditions dans le cadre d'un marché ou d'un contrat. Un contrat vise à fournir un logiciel répondant à des besoins, à un coût fixé. Mais les objectifs ou les prescriptions pouvant évoluer au cours du développement, l'équilibre entre le contenu fonctionnel et l'investissement réalisé par le prestataire peut être difficile à trouver.

De plus, l'estimation des coûts est beaucoup plus complexe à faire dans ce cadre. Enfin, la gestion des délais de livraison, et la qualité des « livrables » est plus difficile à cerner (pas de référence possible à telle fonction décrite dans le cahier des charges et non ou imparfaitement implémentée, par exemple).

La budgétisation de ces projets est plus complexe : il faut prévoir une partie fixe, et une partie variable, qui ne sera utilisée que si nécessaire.

Il faut un demandeur « actif », volontaire, et qui dialogue avec les développeurs. La relation doit être une relation de confiance, non de suspicion réciproque.

Néanmoins, dans tous les petits projets, leur mise en œuvre présente des intérêts indéniables, ne serait-ce que parce que l'implication obligatoire du demandeur augmente les chances que le logiciel sera utilisé in fine.

Sur des projets plus importants, il faut se tourner impérativement vers des méthodes éprouvées si l'on souhaite utiliser la méthodologie Agile, comme PUMA, ou SCRUM/XP, pour bénéficier au maximum de la normalisation qu'elles intègrent. Le passage à l'industrialisation et à la normalisation, au sein de l'organisation, devient alors obligatoire et ne peut être qu'un projet porté par l'entreprise (ou le service).

G.Que faire pour les petits projets ?

Mettre en place une norme, gérer des cahiers des charges et trois acteurs pour un même projet, cela fait « riche » pour de petits projets, souvent menés en interne ou par des équipes réduites, voire un développeur seul dont la tâche principale n'est pas forcément la programmation⁴.

En fait, sur un projet, quatre phases essentielles se rencontrent systématiquement :

• la demande initiale : le demandeur décrit ce qu'il veut, dans les termes qui lui sont propres. Elle est en général insuffisante pour estimer l'ampleur du développement à effectuer. Dans la pratique, il est fréquent que le projet démarre avec une demande très limitée, et que les étapes et modules soient définis en cours de projet ; nous y reviendrons plus tard ;
• La restitution de la demande : l'informaticien va décortiquer la demande, en rencontrant le demandeur, les utilisateurs..., pour circonscrire l'application à réaliser. Le document qui achèvera cette étape constituera le « cahier des charges », c'est à dire ce qui sera demandé à l'application, pour lequel le demandeur est prêt à payer. C'est l'informaticien qui établit le cahier des charges : il devient alors, selon la terminologie classique, l'assistant à maître d'ouvrage. C'est à cette étape que les exigences vont être définies (les contraintes imposées) ;
• Le développement, étape purement informatique, mais qui nécessite plusieurs allez-retours avec le demandeur, pour clarifier certains points ou proposer des approches liées aux évolutions techniques et aux possibilités offertes par les techniques de développement utilisées ;
• La mise en production, qui comprend d'une part les tests de fonctionnement, et d'autre part la mise en route : déploiement sur la plate-forme de production, formation des utilisateurs, reprise de l'historique...

Pour qu'un projet aboutisse, il faut que certains rôles et responsabilités soient parfaitement définis :

• le demandeur est le seul à décider de ce que doit comporter son application. Il doit fournir les ressources financières et humaines nécessaires à son aboutissement. C'est là le rôle du maître d'ouvrage ;
• Le concepteur doit proposer au demandeur la manière de réaliser l'application, les évolutions possibles, et est tenu à l'obligation de résultat. C'est le rôle du maître d'œuvre.

Les deux doivent travailler ensemble : un maître d'œuvre qui refuserait de prendre en compte un point particulier apparaissant en cours de développement, en s'en tenant exclusivement au cahier des charges initial, ne jouerait pas son rôle. Le maître d'œuvre ne doit jamais imposer son point de vue : ce n'est pas lui qui utilisera l'application, et il ne dispose pas de la compétence « métier » du demandeur.

De même, un maître d'ouvrage qui demanderait au maître d'œuvre de s'en tenir au cahier des charges, sans être capable d'évoluer en fonction de critères ou d'impossibilités techniques, qui refuserait de trancher sur des points mis à son arbitrage dans des délais raisonnables eu égard à l'ampleur du projet, manquerait à ses responsabilités.

« Il vaut mieux un mauvais accord qu'un bon procès ».

Pour qu'un projet aboutisse, il faut que chacun assume ses responsabilités et travaille en bonne intelligence. Cela n'exclut pas les conflits, qui sont souvent le résultat d'interprétations liées à des différences d'appréciations sur le cahier des charges, ou des points juridiques sur les droits d'auteur, de licence, de propriété intellectuelle... Si le projet est correctement dimensionné, et si chacun assume son rôle, il n'y a aucune raison qu'il n'aille pas à son terme.

1.La demande initiale

Non formalisée, elle tient en général en une ligne ou une demi-page. L'archétype en est : « il faut informatiser telle procédure nouvelle, c'est un écran et un état, et c'est pour demain ».

Le premier travail consiste à rédiger la demande pour qu'elle puisse être exploitable, en s'attachant à définir :

• l'objectif visé ;
• les matériaux (de quoi l'on part) ;
• le cadre juridique ;
• les délais souhaités.

L'informaticien, à ce stade, peut jouer un rôle de faciliteur, en aidant à faire exprimer la demande. Bien souvent, il faut « décrypter » le message, en isolant ce qui ressort de la valorisation personnelle du demandeur, pour prendre en compte la demande réelle. Deux écueils sont à éviter :

• d'une part, limiter le périmètre du projet en faisant confiance au demandeur, qui va s'auto-censurer. Cas typique : « cette fonction, ce n'est pas la peine, ça représente trop peu de dossiers, on n'en aura pas besoin ». En général, à ce stade, il est bon de noter le point abordé, qui peut être parfois très structurant pour la suite du projet, même s'il n'est pas prévu de l'informatiser dans la phase initiale ;
• d'autre part, porter un jugement sur la faisabilité (ou plutôt sur la non-faisabilité) d'une fonction ou d'une partie de la demande. C'est le rôle de l'analyse préalable de s'assurer dans quelles conditions la réalisation ou la mise en œuvre sont possibles, pas de la demande initiale.

En résumé, il faut mettre en forme la demande, qui doit être la plus complète possible, avec, si nécessaire, un premier exercice de définition des priorités.

Dans la pratique, quand on développe à l'intérieur de sa société, la demande est orale... C'est à l'informaticien de la mettre par écrit, et de faire valider (et corriger) le document par le demandeur. Il est souvent beaucoup plus facile de se positionner ou de répondre à un texte déjà écrit plutôt que de partir de la page blanche. Et en plus, le demandeur à qui on aura transcrit sa demande sur papier aura un a priori largement favorable : non seulement vous avez su l'écouter, mais vous avez également su retranscrire sa demande !

Un projet s'inscrit dans un contexte : on ne part pas de rien. Des contraintes existent, qu'elles soient implicites (l'application doit être utilisée avec un micro-ordinateur fonctionnant sous le système d'exploitation le plus courant) ou explicitées dans la demande initiale.

Un projet ne pourra aboutir que s'il prend en compte les contraintes suivantes :

• le demandeur paye le produit. Il est normal que le logiciel rende les services qu'il a demandé ;
• les utilisateurs vont travailler avec le logiciel régulièrement. Il doit s'intégrer dans leurs habitudes de travail, tant en terme d'ergonomie que de processus (si ceux-ci ne sont pas redéfinis à l'occasion de l'arrivée du nouveau logiciel) ;
• il existe une réglementation, et le logiciel doit s'y conformer. Très souvent, les contraintes réglementaires sont trop souvent ignorées ou mal prises en compte. Le demandeur connaît la procédure, mais va passer sous silence « ce qui va de soit ». Il est indispensable de se procurer les textes réglementaires ad-hoc et de les intégrer dans sa réflexion (règles comptables, lois, décrets, circulaires d'application, normes en vigueur...) ;
• le projet s'insère dans un existant, composé de serveurs, de bases de données, d'outils... Si un logiciel est écrit en s'appuyant, par exemple, sur Java pour le code et MySql pour la base de données, mais que le client impose un développement avec WinDev et une base de données postgreSql, il est normal que le client refuse de payer l'application qui lui sera fournie...

Au final, le projet s'intègre au sein de quatre éléments : le demandeur, l'utilisateur, les contraintes techniques et les contraintes réglementaires.

Ne pas tenir compte d'une de ces contraintes, c'est s'exposer à de graves difficultés, soit lors de la phase de développement (le demandeur se rend compte que le produit ne répond pas à sa demande), soit dans la phase de test et de mise en production (les utilisateurs ne veulent pas utiliser le produit parce qu'il ne correspond pas à l'application qu'ils font de la procédure), soit en production, quand on s'aperçoit que le logiciel ne respecte pas la réglementation.

2.La restitution de la demande

Il s'agit de formaliser ce qui a été compris de la demande. Cette restitution va permettre :

• de vérifier le périmètre du projet ;
• de préciser certains points techniques. Par exemple, si la demande initiale prévoit l'import de données statistiques, il faudra se préoccuper de savoir d'où viennent les données, quel est leur format, quelle est la fréquence d'importation...
• de pouvoir estimer le « volume » du projet, et de définir les différentes phases et modules.

C'est lors de cette phase que la viabilité du projet va être étudiée.

Pour restituer la demande, et en partant du principe qu'un mauvais dessin vaut mieux qu'un grand discours, il est préférable de s'appuyer sur un certain nombre de schémas UML :

• les cas d'utilisation, qui permettent d'identifier les différents modules potentiels. Chaque cas d'utilisation débute par un schéma représentant les acteurs et les grandes fonctions. Mais le plus important est la partie rédactionnelle qui suit, et qui va décrire, de façon la plus précise possible, ce qui va être réalisé ;
• les diagrammes de fonctionnement (diagramme d'activité, de collaboration), qui vont permettre d'expliciter certains flux ou fonctions complexes ;
• les diagrammes d'objets et de classes, qui permettent de représenter les objets facilement compréhensibles par des non informaticiens, et de restituer la classification qui est faite de ces objets.

Ce document doit faire l'objet d'une validation de la part du demandeur (le maître d'ouvrage). Cette validation est essentielle : elle permet à chacun de partir d'une plate-forme commune, même si cette plate-forme peut évoluer au fil du temps.

3.L'analyse initiale

Elle est destinée aux informaticiens. Elle vise à dégrossir les processus, et doit impérativement déboucher sur une maquette.

On va utiliser de façon intensive les diagrammes d'objets et de classes pour décrire les entités manipulées, associés aux diagrammes de collaboration, voire d'activité.

A ce stade, on montre principalement les classes « physiques », celles qui représentent les objets réels, et qui seront pour la plupart implémentées en partie dans la base de données. On peut faire apparaître, si c'est nécessaire, des classes virtuelles, comme les modules de calcul ou de traitement lourd (exports, calculs financiers...).

Les grands ensembles de traitement (les modules) doivent être identifiés. C'est ce qui permettra de hiérarchiser le développement, c'est à dire l'ordre dans lequel les modules seront réalisés.

Il est fréquent que l'analyse initiale soit très réduite, voire inexistante : le plus simple est de commencer à coder un premier module, puis de rajouter, au fur et à mesure, les modules suivants en fonction des retours du demandeur (feedback). C'est au moment du codage qu'on réalisera les schémas nécessaires pour expliciter ce que doit faire le module, et comment.

4.Le développement

Il y a quelques années, je conseillais de réaliser une maquette, puis de passer par une phase d'analyse, et enfin de coder... Aujourd'hui, la prise en compte de certains éléments des méthodes agiles me semble beaucoup plus cohérent.

Sauf si vous êtes un développeur aguerri, fixez-vous des itérations d'une durée constante et pas trop longues : pour moi, l'idéal est de 2 semaines. Avec le demandeur, faites une réunion toutes les 2 semaines pour :

- présenter le travail réalisé pendant la quinzaine ;

- fixer les objectifs pour les deux semaines à venir.

L'objectif d'une itération est de réaliser un module fonctionnel. Cela peut être, au début, d'implanter le framework, de mettre en place les outils de développement (gestion des versions, choix des bibliothèques, tests divers de faisabilité...). Puis il faudra s'astreindre à fournir quelque chose de fonctionnel : c'est typiquement un module de saisie, qui comprend :

- une zone de sélection (les critères de sélection) ;

- l'affichage d'une liste des enregistrements correspondants ;

- la création / modification d'une fiche.

Par la suite, cela peut être l'implémentation de fonctions de contrôle, des éditions, etc.

Ainsi, même si le projet n'est pas terminé à la fin de la période (fin du stage, par exemple), ce qui a été déjà développé sera fonctionnel et pourra, probablement, être utilisé ou complété. Le travail n'aura alors pas été réalisé pour rien⁵ !

L'intérêt de travailler par itérations, c'est que cela permet également au demandeur de se rendre compte assez vite si le projet dévie ou pas. Il peut remettre en question des choix techniques : ce n'est pas très grave, s'il n'y a que 2 semaines (au pire) de perdues ! Si cela se fait à la fin du projet, c'est, alors, une catastrophe.

Donc, même si vous travaillez tous seul et que le demandeur de l'application est rarement disponible, essayez de lui imposer une réunion régulière toutes les 2 semaines pour faire le point : c'est le minimum qui vous permettra de travailler à peu près correctement.

5.Comment aborder le développement

Surtout pour un jeune développeur, commencer à coder est difficile : le syndrome de la page blanche n'est pas loin...

Dans un premier temps, choisissez de coder un module simple, par exemple la saisie d'une fiche. Ce module va comprendre, en général :

- un écran de sélection ;

- une liste d'affichage des enregistrements correspondants ;

- un écran d'affichage du détail d'une fiche ;

- et enfin, l'écran de création / modification.

Commencez par dessiner un schéma général de fonctionnement en UML (diagramme de séquence, mais pas seulement, si vous voulez représenter l'enchaînement global, c'est à dire comment vous naviguez entre vos différents écrans).

Vous aurez très probablement besoin d'écrire la classe qui vous permettra d'accéder à vos informations (souvent, basée sur un moteur ORM – cf. II.E - Le couplage relationnel-Objet, page 27). Avant de créer votre classe, commencez par dessiner les tables qui seront nécessaires (il est possible que vous aurez besoin de tables de sélection, par exemple la table des civilités pour la saisie d'une fiche « individu »). Utilisez pour cela des outils qui permettent de générer le code de création des tables automatiquement, y compris quand vous réaliserez des modifications⁶.

Une fois vos tables générées, codez d'abord l'affichage de la liste, puis l'écran de création/modification d'une fiche : vous pourrez ainsi commencer à alimenter votre table. Rajoutez l'affichage du détail, puis les critères de recherche.

L'écriture du premier module sera probablement long : les modules suivants iront plus vite...

6.Le codage objet : quelques écueils possibles...

Le développement objet présente plusieurs avantages :

• facilité de maintenance
• fiabilité du code
• vitesse de programmation

Mais également des inconvénients :

• longue phase de codage avant de pouvoir « voir » quelque chose fonctionner (on code les classes avant l'interface)
• les performances sont moins bonnes en général qu'un développement classique, l'utilisation de classes induisant très souvent plus de lignes de codes et plus de ressources lors de l'exécution. Selon ce qu'on veut faire, il faut alors trouver le bon compromis entre la facilité de maintenance et la vitesse d'exécution. Il faut aussi estimer la charge machine nécessaire : une application destinée à une dizaine d'utilisateurs sera plus tolérante qu'une application web destinée à supporter plusieurs millions de connexions simultanées !
• Il faut également se méfier du « tout objet ». Si coder l'accès à une table dans une classe n'apporte que des bénéfices, l'exécution d'un module, qui va enchaîner un certain nombre d'opération successives., n'a rien à gagner à une organisation en fonctions, le code étant, alors totalement linéaire.

À ce sujet, une petite remarque vis à vis de PHP... Ce langage a pas mal de défauts (pas de typage des variables, par exemple, exécution interprétée), mais il a su, au fur et à mesure de son évolution, conserver son atout principal, à savoir la possibilité de faire cohabiter du code séquentiel (ou procédural) avec une gestion de classes. Cela lui donne une grande souplesse, ce qui permet de coder beaucoup plus vite qu'avec bien d'autres langages.

Pourtant, certains frameworks « professionnels », comme Symphony⁷, par exemple, ont décidé que le code procédural était à bannir, et ont copié le mode de développement utilisé en java. Dans ce cas, pourquoi développer en PHP, et pas en java ? J'avoue avoir du mal à comprendre la logique...

7.Les tests

On distingue souvent deux types de tests, les tests unitaires, ceux qui sont effectués par le développeur, et les tests approfondis qui permettent de s'assurer que l'application répond à l'ensemble des besoins

Les test unitaires servent à s'assurer que le code fonctionne de façon correcte, de manière indépendante.

On va créer un jeu de tests, portant sur plusieurs items, et prenant en compte l'ensemble des cas de figure qu'on a intégré lors de la programmation. Chaque module doit être testé de façon indépendante, pour ne pas avoir de « pollution » par du code non débogué. L'important est de tester au fur et à mesure, pour s'assurer que ce qu'on vient d'écrire est cohérent. Si on ne fait pas ce travail, le débogage devient alors vite fastidieux pour retrouver le module qui pose problème. Utiliser des outils susceptibles d'afficher le contenu des variables et de mettre des points d'arrêt apporte un confort certain : la plupart des outils intègrent un débogueur, mais on peut aussi en simuler un en arrêtant l'exécution et en affichant manuellement les variables qui posent problèmes.

Les tests unitaires sont surtout utilisés pour vérifier le fonctionnement de l'interface.

Les tests approfondis vont permettre de s'assurer que l'application répond au besoin. Ils ne devraient pas être réalisés par le développeur, qui pourrait facilement les bâcler.

Aujourd'hui, les professionnels des tests recommandent de les décrire au moment où l'on définit les besoins. Cela va permettre de préciser la demande et d'éviter les biais liés au processus de développement (on modifie inconsciemment ce qu'il faut tester en fonction de ce qu'on a réalisé).

Il est préférable de faire tester par des personnes qui n'ont pas travaillé sur le développement, en y intégrant le demandeur (ou maîtrise d'ouvrage). La phase de test est un processus hélas trop souvent bâclé, qui aboutit souvent à des coûts cachés (bugs découverts sur le tard).

Les tests doivent s'attacher à expertiser la conformité de l'application :

• vis à vis de la demande (l'application répond-elle bien à ce qu'on a demandé ?) ;
• vis à vis de la réglementation ;
• vis à vis des utilisateurs (est-elle adaptée au travail et aux habitudes quotidiennes ?)

Il faut ainsi impliquer plusieurs profils d'utilisateurs différents !

Dans la pratique, pour des applications relativement modestes, il faut prévoir une année de mise au point et de correction de bugs à partir de la mise en production. Au delà, les bugs sont nettement plus rares (courbe logarithmique). La correction est en général plus simple, le code plus « propre », en développement objet.

8.La rédaction de la documentation

Avec les logiciels modernes, il est souvent superflu de réaliser des guides d'utilisation très détaillés, surtout si l'application doit être utilisée par un nombre restreint d'utilisateurs qui maîtrisent bien leur procédure⁸. Par contre, il est important de rédiger le guide « Administrateur », qui va décrire la solution technique retenue, l'implémentation de la base de données, le paramétrage, et la gestion des droits.

Sans ce document, il est souvent quasiment impossible de mettre en production le logiciel, surtout si celle-ci est décalée dans le temps.

Le code devra contenir des commentaires... normalisés !

1Source : http://fr.wikipedia.org/wiki/Manifeste_agile

2Source : http://fr.wikipedia.org/wiki/Méthode_agile

3Source : 01 Informatique du 13/03/2008

4Ce fut mon cas pendant plus de 25 ans !

5Je ne compte plus les logiciels ou les développements arrivés à maturité, mais jamais utilisés, ou si peu...

6Si vous travaillez avec une base de données Mysql, vous pouvez utiliser SQL Workbench - http://www.mysql.fr/products/workbench/. Avec les autres bases de données, Moskitt est probablement le plus complet, même s'il est plus complexe d'utilisation et comprend quelques limitations ou quelques bugs (http://www.moskitt.org/eng/)

7Ce framework présente d'autres inconvénients, dont notamment le fait qu'il dispose de son propre langage, et qu'il n'est pas réputé pour sa « frugalité » en ressources sytèmes...

8Et à condition que l'ergonomie respecte les standards... J'avoue avoir été particulièrement intrigué devant des logiciels « modernes », écrits en « full Ajax », qui m'ont laissé perplexe sur leur utilisation... Bien qu'étant informaticien et connaissant l'usage qui devait en être fait, j'ai du me retourner vers la documentation ou les formateurs pour comprendre comment les utiliser...