Le rôle de la conception dans les projets

Tout le monde connaît des applications qui sont désespérément lentes, des sites Web tellement touffus que le visiteur finit par s’y perdre, des traitements fonctionnant normalement et qui soudain, sans prévenir, sortent des résultats aberrants, … Tous ces incidents sont des signes qui ne trompent pas. Tout professionnel vous le dira : « Il y a un problème de conception ». Il est même possible qu’il n’y ait pas eu de conception (¹) et cela se voit.

Normalement tout projet informatique comprend avant la réalisation (²) une phase de conception plus ou moins importante. Le nom de cette étape varie mais on la retrouve dans toutes les démarches : approche classique, prototypage, démarche en spirale, méthode agile, …. Cette étape est très importante car elle permet de s’assurer que rien d’important n’a été oublié, que l’application envisagée est techniquement réalisable et qu’elle fonctionnera convenablement.

L’expérience montre que sans une étape conception le projet dérive et fini par se « planter ». Plus de 65 ans de développement de logiciels montrent son importance. Jadis elle était assez succincte. En quelques jours on rédigeait un court document illustré par quelques schémas. Aujourd’hui on n’hésite pas à passer du temps à définir ce qu’il est souhaitable de faire faire à l’application et la manière de procéder pour y arriver. Mais jusqu’où faut-il aller ? Les méthodes agiles suppriment l’étape consacrée à l’élaboration du cahier des charges. Est-ce la bonne approche ?

Mais qu’est-ce qu’au juste la conception ?

Fausses conceptions sur la conception.

Avant d’aller plus loin il faut commencer par faire un sort à certaines vieilles lunes concernant la conception. En effet, il existe en ce domaine un certain nombre d’idées assez inexactes, voir franchement inexactes :

• La conception est du temps perdu. Les tenants de cette approche pensent qu’il est préférable de commencer très vite par programmer puis ensuite d’ajuster le code en fonction des retours des premiers utilisateurs (³). Ce type d’approche amène à réaliser une 2^ème puis une 3^ème version, … C’est du « quick and dirty » et plutôt du « dirty-dirty ».
• L’analyse fonctionnelle consiste à recueillir les besoins de tous les intéressés pour définir les spécifications de la future application. On va pour cela multiplier les entretiens, les groupes de travail et les travaux de synthèse. Cela correspondant au souhait d’être sûr de ne rien oublier. Il faut être claire : la conception n’est pas la collecte de toutes les doléances de tous les utilisateurs potentiels. C’est un préalable mais ce n’est pas la conception proprement dite.
• On conçoit l’application indépendamment des choix techniques et organisationnels qui sont ensuite effectués. Or la dimension fonctionnelle n’est qu’une partie des spécifications de la future application. Les performances, la sécurité, les contraintes qui s’imposent dans le domaine technique, la maintenabilité, la fiabilité des traitements, … sont des éléments importants à prendre en compte dans la conception de l’application.

La conception s’est autre chose. C’est une vision globale de la future application et la manière de la développer de façon à arriver à une solution efficace et élégante.

Le secret des projets à succès

Heureusement un grand nombre d’applications sont bien conçues. L’observation montre qu’il existe aussi un certain nombre d’autres applications mal foutues. Ce sont celles dont les utilisateurs se plaignent fréquemment. Et très souvent on constate que ceci est dû à des faiblesses de conception. L’expérience montre que l’absence de conception se traduit par le développement « d’usines à gaz » ou par des « plats de nouilles ». Ceci se traduit par un grand nombre de « bugs » qui, finalement, produisent de nombreux « plantages » d’exploitation (⁴).

A l’inverse une application efficace repose généralement sur une conception de qualité. Cela se manifeste par des temps de réponses excellents, une succession d’opérations simple, les traitements sont sûrs, les bases de données sont de qualité et fiables, la maintenance se fait sans peine, …. Lorsque la conception est de qualité cela se voit.

Ceci ne veut pas pour autant dire qu’il est nécessaire de rédiger un cahier des charges de 500 pages touffues et difficiles à comprendre. La qualité de la conception ne se mesure pas au nombre de pages produites mais à la quantité et la qualité du « jus de cervelle » qui sont investies dans le projet.

L’observation montre que la qualité de la conception se manifeste de deux manières :

• une économie de moyen. Peu de ressources sont nécessaires pour développer le projet. Celui-ci se déroule rapidement et arrive aux résultats attendus dans les délais prévus. Autre point significatif, l’application bien conçue a besoin pour fonctionner d’un volume de ressources informatiques raisonnables.
• une grande souplesse du système. Il est apparemment simple d’emploi et a une capacité d’évolution satisfaisante de sorte qu’il s’adapte sans trop d’effort à un changement du contexte.

Mais ces deux caractéristiques, économie de moyen et grande souplesse, ne sont pas propres à l’informatique. Elles concernent aussi d’autres domaines comme la conception et la réalisation d’ouvrages d’art comme les ponts, mais aussi le développement d’avions, de moteurs, … C’est le résultat de la mise en œuvre d’un savoir-faire particulier, c’est presque un tour de main. Ceci montre que la conception n’est pas une science mais plutôt un art.

L’expérience montre que certaines personnes sont de bons concepteurs et que d’autres ne le sont pas. Ce n’est pas un problème de formation. Il arrive que des personnes bardés de diplômes s’avèrent être des concepteurs médiocres alors qu’à l’inverse des personnes nettement moins diplômés sont excellents en ce domaine. Des formations aux techniques de gestion de projet améliorent leur efficacité mais elle ne permet pas d’acquérir la capacité à faire de bonnes conception. C’est, à la base, une affaire de talent et de créativité.

Le rôle du concepteur

Dans le processus de développement le concepteur joue un rôle particulièrement important. Mais les termes usuellement employés pour décrire la fonction de concepteur sont ambigus. Ce sont soit des analystes soit des chefs de projet :

• L’analyste. On précise souvent que c’est un « analyste fonctionnel ». En fait ce n’est pas analyste, car il n’analyse pas mais au contraire conçoit, et il ne limite pas son intervention au seul domaine fonctionnel. Il n’a pour mission de décomposer le futur système en unités élémentaires mais au contraire d’imaginer une solution globale cohérente. Le titre d’ «analyste» devrait être évité. Celui de «concepteur» serait préférable.
• Le chef de projet. Très souvent le concepteur est désigné par le terme de chef de projet mais au moment de la conception de l’application il n’y a pas encore de projet. De plus il travaille seul ou avec un ou deux collaborateurs. Le terme de chef de projet est en avance par rapport à la suite des événements. Par contre en phase de réalisation il peut devenir chef d’équipe mais il est difficile d’être à la fois concepteur et chef de l’équipe de réalisation car cela ne fait pas appel aux mêmes compétences.

En fait le rôle du concepteur ressemble assez à celui d’un architecte (⁵). Le concepteur informatique commence faire une étude généralement appelée expression des besoins ou étude de faisabilité. Ce premier travail ressemble beaucoup à l’étude faite par les architectes appelée «esquisse» ou «plan masse». Ensuite le concepteur va effectuer une analyse fonctionnelle qui se traduit par cahier des charges. Ce travail est assez voisin de celui de l’architecte appelé «avant-projet définitif» ou «dossier d’appel d’offre» (dossier d’APO).

On notera que la conception en informatique comme en architecture se fait en deux étapes : une conception globale (ou conception d’ensemble) suivie ensuite une conception détaillée. Un jour un stagiaire qui suivait un cours de gestion de projet m’a demandé pour quelle raison il y avait deux étapes. J’ai été perplexe et j’ai fini par lui répondre : «c’est l’habitude car on évite de mettre tous les œufs dans le même panier». On retrouve cela dans toutes les démarches d’ingénieries.

Certaines méthodes agiles comme Scrum ou Extreme Programming ont cherchés à ramener la conception à une seule étape d’initialisation ou de cadrage, souvent basée sur des scénarios d’utilisation. Ce sont en fait des études de faisabilité. Par contre toutes les méthodes agiles bannissent l’étape d’analyse fonctionnelle. Malheureusement cette étape a un double rôle fondamental : s’assurer que rien d’essentiel n’a été oublié et évaluer l’effort de programmation et de tests nécessaire pour arriver à une application opérationnelle. Résultat : la probabilité de dérive augmente.

Comme on le voit le rôle de la conception est fondamental. Qu’elle se fasse en une ou deux étapes, elle est indispensable et le concepteur est l’acteur principal de cette étape. Son rôle est de construire un système simple et efficace à partir d’un ensemble hétéroclite : des idées plus ou moins bien formulées, des demandes hétérogènes faites par les utilisateurs, de nombreux documents, différentes études techniques, des entretiens, les travaux de groupes de travail, des spécifications, …. En fait un bon concepteur est un homme de synthèse. C’est un véritable «artiste» : un homme de l’art connaissant tous les aspects de la réalisation de système d’information et capable d’effectuer les choix des solutions les plus efficaces.

Tentative de définition de la conception

Comme on le voit il n’est pas facile de définir ce qu’est la conception. C’est un peu comme la définition de l’escalier en colimaçon. Si vous demandez à quel qu’un ce que c’est-il hésite puis fini par faire un geste de la main pour montrer que cela monte en tournant. Bien sûr il existe dans le dictionnaire une définition : « c’est un escalier qui s’enroule sur lui-même ». C’est beau mais ce n’est pas d’une grande clarté. Une approche empirique est préférable.

Pour mieux cerner la définition du travail concepteur deux points clés se dégagent. Il doit d’abord avoir la capacité à intégrer toutes les contraintes et définir de manière claire le périmètre fonctionnel de l’application. Il va notamment définir ce qui fait partie de la future application et ce qui n’en fait pas partie. Il doit ensuite être capable de fixer un budget et un délai pour réaliser le projet. Il va pour cela effectuer des arbitrages budgétaires tout en tenant compte des contraintes de ressources et de délais.

Un de mes amis, qui est un excellent concepteur, à l’habitude de dire que : «la conception consiste à fermer des portes en disant : «ça je ne le ferais pas» ». Au-delà de la boutade il y a une réalité. Face à chaque demande et à chaque spécification il doit s’interroger sur l’effort nécessaire pour le réaliser et son utilité. Pour cela il suit une démarche qui n’est pas sans rappeler celle de l’analyse de la valeur. Souvent le concepteur dit : «ce sera dans la version 2». C’est la manière polie de «fermer les portes».

Il est plus facile de reconnaître une mauvaise conception

Mais comment définir une bonne conception ? En fait, il est plus facile de constater qu’une application a été mal conçue alors qu’il est plus difficile de définir pour quelle raison une autre application est bien conçue. En effet les systèmes mal conçus ont quelques caractéristiques communes :

• Lenteur. Les saisies sont lentes et les traitements poussifs. Les utilisateurs se plaignent souvent de devoir attendre devant les écrans qu’ils se déverrouillent. De même les contrôles sont fastidieux et peu efficaces.
• Touffue. Très vite l’utilisateur se plaint d’être perdu dans la succession des opérations et ne plus savoir ce qu’il doit faire. Les fonctions sont confuses, les libellés ne sont pas clairs, … Ceci fait que les utilisateurs commettent fréquemment des erreurs de navigation ou de sélection des traitements.
• Peu efficace. L’application informatique mise en œuvre n’a pas permis de dégager des gains significatifs (gains de productivité, augmentation du chiffre d’affaires et du bénéfice de l’entreprise).
• Sécurité insuffisante. Le système est jugé peu fiable par ses utilisateurs. Les données sont mal sécurisées. Les redémarrages sont longs et laborieux et il arrive que des données soient perdues. Pire, on s‘en aperçoit au bout de quelques semaines, voir de plusieurs mois après l’incident qu’il est très difficile voir impossible de reconstituer les données perdues.  

Ces symptômes sont en grande partie liés à des faiblesses de conception ou à la médiocrité de la réalisation. On le sait : une conception médiocre ne peut qu’entraîner une réalisation médiocre. Malheureusement ces défauts ne peuvent qu’être constaté qu’a posteriori lorsque l’application est mise en production et il est alors généralement trop tard pour corriger la faiblesse de la conception.

Autre signe qui ne trompe pas : lorsque l’application mal conçue devient opérationnelle on constate, que la maintenance nécessaire est anormalement élevée, difficile à effectuer et coûteuse. Malheureusement, à ce moment il est trop tard pour corriger ces défauts (⁶).

Il est préférable de détecter ce type de fragilité dès la phase amont. Malheureusement, l’expérience montre qu’il est difficile de constater à ce moment la faiblesse de la conception. Cependant il existe des signes annonciateurs. Ainsi si l’étude de faisabilité ne fixe pas de manière claire et non-ambigu le périmètre fonctionnel on risque de constater par la suite une dérive significative. Ensuite, lors de la phase fonctionnelle on constate que le document final type cahier des charges est verbeux, par clair et assez filandreux. C’est un critère simple : « si vous ne le comprenez pas ce n’est pas de votre faute. C’est dû au fait que la conception est faible, voire mauvaise ». Deux autres critères permettent d’évaluer ce document :

• Il est lourd et difficile à lire.
• Il part dans tous les sens.

Comme les fragilités de la conception peuvent avoir de graves conséquences il est important de veiller à avoir de bons concepteurs.

Trouver un bon concepteur

Malheureusement il est très difficile d’arriver à détecter a priori quelles sont les personnes qui ont de bonnes capacités de conception. Rien ne permet de présumer ces compétences. Tant qu’on n’a pas mis les personnes en situation on ne saura pas si elles ont des compétences de conception. Comme le dit le proverbe : «C’est au pied du mur qu’on voit le maçon».

Un minimum de connaissances est nécessaire : une bonne culture informatique, une solide pratique de la gestion et une connaissance approfondie du domaine à informatiser. C’est une base nécessaire mais ce n’est pas suffisant.

Il est pour cela nécessaire de tester un certain nombre de personnes pour découvrir celles qui ont de réelles compétences de conception. On a souvent d’heureuses surprises mais fréquemment de nombreuses déceptions.

Pour ces raisons il est nécessaire de cultiver dans l’entreprise ces compétences et surtout de les conserver. Pour choisir les personnes deux orientations sont envisageables  :

• une solide culture technique du type ingénieur ou équivalant. Ce sont fréquemment des informaticiens mais ce peuvent aussi être des ingénieurs mécaniques, électriques, chimiques, travaux publics, … Souvent de simples techniciens ont des capacités insoupçonnées.
• une forte culture d’entreprise notamment dans les domaines de la gestion et de management. Pour être efficaces il est indispensable que ces personnes aient aussi une bonne connaissance de l’informatique.

On constate qu’actuellement les entreprises recherchent plutôt des personnes du deuxième type capable de comprendre les préoccupations du management et les demandes des futurs utilisateurs tout en étant capable de dialoguer avec les informaticiens.

Souvent, n’ayant pas en interne ces concepteurs, les entreprises font appel à des SSII (⁷) et à des cabinets de conseils car elles ont souvent des concepteurs de bonne qualité car ils ont vu de nombreuses entreprises et effectuer une grande variété de missions. Mais il y a aussi parmi leurs collaborateurs des personnes nettement moins efficaces, à éviter.

L’absence de concepteur peut être fatale

Dans les entreprises qui se développent rapidement, notamment celles qui se sont résolument engagées dans leur transformation numérique, on constate que le nombre de projets est supérieur aux nombres de concepteurs disponibles. C’est une grave contrainte. Des demandes importantes sont bloquées ou, pire, des projets sont lancés sans conception où avec une conception réduite au strict minimum. Les résultats ne sont pas à la hauteur des espérances même pour des réalisations de taille limitées.

Face à cette situation deux solutions sont envisageables selon l’importance du projet :

• Dans le cas d’un petit projet la solution consiste à faire du « versionning » en développant des versions successives. C’est la démarche proposée par le mode agile. On sort une nouvelle version tous les 2 mois. Cela peut être des versions offrant de nouvelles fonctions ou des réécritures successives de versions antérieures (on parle dans ce cas de «ravaudage»).

Cette démarche à l’avantage de permettre de limiter les risques de dérives fonctionnelles des projets. Par contre elle risque de se traduire par des coûts supérieurs à ce qui étaient prévus à l’origine. A cela s’ajoute le coût élevé de la maintenance nécessaire demandée par une application développée de cette manière. Il peut devenir si élevé qu’il est souvent préférable de réécrire entièrement l’application à «iso-fonctionnalités».

• Dans le cas de grands projets, si on n’a pas en interne de concepteur ayant le savoir-faire nécessaire, il faut commencer par voir s’il n’est pas possible de dégager un concepteur faisant fonction de chef de projet en le remplaçant par un chef d’équipe de développement capable de contrôler les équipes sans toucher au contenu des fonctions à développer.
  Si ce n’est pas possible il faut alors envisager de sous-traiter la conception de la future application. Dans ce cas une attention particulière doit être portées aux personnes déléguées par les sociétés de service ou de conseil. Il faut étudier avec soins les CV des personnes proposées et leurs références et avoir un long entretien préalable avec elles.

Si on ne dispose pas de la personne ayant les compétences nécessaires il est préférable de ne pas lancer le projet et d’attendre de trouver la personne compétente.

Il est aussi possible de découper en plusieurs petits projets plus facile à maîtriser par des personnes moins expérimentées. On parle dans ce cas de «saucissonnage». Faut-il encore que l’application s’y prête ?

Contrairement à ce qui est souvent dit, la qualité de la conception n’est pas une affaire d’outils ou de méthodes. Ils sont utiles mais ils ne font pas le travail de conception. Celle-ci est d’abord une affaire de compétences. Les entreprises doivent cultiver ce type de savoir-faire. Si ce n’est pas le cas, leurs projets risquent de dériver, voire d’échouer. L’expérience montre que des applications développées dans ces conditions risquent d’être lourdes et peu efficaces. A l’inverse les systèmes d’information efficaces reposent toujours sur une conception de qualité faite par un concepteur compétent. Cette constatation ne souffre pas d’exception.

1 - Le terme conception utilisé en France n’est pas parfait. Le terme anglais de « design » est plus juste même s’il est un peu trop restrictif.

2 - Parfois on fait l’inverse : on commence par programmer puis au bout d’un certain temps les programmeurs s’interrogent et se demandent comment « raccrocher les morceaux ». On cherche alors à dégager une sorte de conception. Généralement le résultat est assez décevant. Il est de loin préférable de commencer par la conception pour ensuite effectuer la programmation.

3 - C’est le fameux « Fixe and Code » des débuts de l’informatique. Cette démarche a en règle générale donnée des résultats décevants et elle a été progressivement abandonnée au profit de démarches plus structurées commençant par une phase de conception. Mais aujourd’hui encore on constate que cette démarche est encore pratiquée avec des résultats toujours aussi décevants. Si l’application se limite à développer 2 ou 3 programmes, il est vrai que le risque est limité. Au-delà on entre dans la « terra incognita ».

4 - La terminologie des professionnels est sur ce sujet particulièrement riche. « L’usine à gaz » est une application lourde et peu efficace. L’utilisateur doit faire beaucoup d’efforts pour finalement constater un résultat décevant. « Les plats de nouilles » sont des programmes mal bâtis. Ils sont foisonnants, avec de nombreux renvois en tout sens ce qui les rendent peu lisibles. Le terme « bug » est rentré dans le langage courant. C’est une erreur dans une instruction qui se traduit finalement par un « plantage ». Le terme est charmant mais la réalité est mal vécue par les utilisateurs qui, lorsqu’ils tombent sur un « bug », perdent une partie des données qu’ils viennent de saisir.

5 - Dans quelques entreprises on les appellent «architecte fonctionnel». Mais ce titre est, en fait, assez peu utilisé.

6 - On peut effectuer une analogie avec le bâtiment. Lorsqu’une maison est terminée, si on s’aperçoit au bout de quelques mois que d’importantes fissures apparaissent et si on estime qu’elles sont dues à des fondations insuffisantes (ou à une absence de fondations) il est alors difficile de corriger ces défauts. On peut faire des injections de béton mais il n’est pas sûr que ce soit suffisant.

7 - On les appelle de plus en plus souvent les entreprises de services du numérique (ESN).