Faites connaître ce billet :

Travailler sur un projet d’application accessible depuis le web, surtout si elle a une visée professionnelle, c’est avant tout réfléchir avant d’agir. En effet, si j’ai pour habitude de dire que la programmation est très abordable car elle vise à enchaîner, comme on le ferait avec des légos, une succession d’instructions simples au service d’une construction… il n’en demeure pas moins que la construction finale peut être énorme. Chacune des petites briques doit donc être solide, et positionnée judicieusement.

Quelques questionnements de base sont indispensables avant de se lancer… et ce billet vise à en étudier quelques-uns, rassemblés au fil de mes expériences et de l’aide que j’ai pu apporter à d’autres programmeurs via notamment les forums d’OpenClassroom :

  • Quels sont les différents types de données que l’on va utiliser ?
  • Quelle organisation ces données doivent-elles avoir entre elles ?
  • Quelles sont les différentes personnes qui vont utiliser les données ?
  • Quel est le “flux” de travail que l’on veut traduire numériquement ?
  • Quelles sont les différentes formes “finales” que l’on cherche à obtenir ?

Je reste naturellement ouvert à toute suggestion, remarque ou même à toute information complémentaire que vous trouveriez adaptée !

Quels sont les différents types de données que l’on va utiliser ?

Cette question est loin d’être anodine car elle conditionne l’un des aspects les plus essentiels d’une application web : la structure de base de ses données. En effet, le but d’une application est de permettre l’entrée, le traitement, et la sortie de données. Mais face à une montagne d’information vous n’allez pas réagir de la même manière…

Illustration : un entrepôt (Marcin Wichary sur Flickr)

Illustration : un entrepôt (Marcin Wichary sur Flickr)

Perles, vaisselle, DVD ou livres ?

Comme dans la vraie vie, on ne range pas tout de la même façon. Des perles, de la vaisselle, des DVD ou les livres d’une bibliothèque vont nécessiter des traitements particuliers et n’auront pas les mêmes caractéristiques de base. On peut poursuivre la métaphore…

Les locaux doivent être adaptés : un quai de déchargement peut être une bonne idée lorsque de grosses quantités d’objet vont arriver régulièrement par camion, ce qui implique l’usage d’outils particuliers (le transpalette) et donc des adaptations spécifiques… la largeur des portes par exemple. Niveau applicatif, cela signifie par exemple prendre en compte les imports de données extérieures…

Le stockage est à prendre en compte : empiler des livres sur des rayonnages n’a aucun sens sans un minimum d’organisation et sans mettre en place le moyen de retrouver rapidement celui qu’on cherche par la suite. Un gros avantage des applications web est qu’elles peuvent prendre en charge elles-même le rangement, mais elles ne peuvent pas deviner les critères qu’elles doivent utiliser pour cela. Niveau applicatif, cela signifie par exemple que la manière de renseigner un élément va différer selon sa nature.

Et enfin la présentation d’un résumé synthétique des opérations peut avoir des objectifs très différents : savoir qui est en retard dans le retour d’un DVD loué, savoir quels sont les livres qui ne sont jamais recherchés ou prêtés pour savoir lesquels “désherber”, etc. Ces différentes informations doivent être présentées de manière cohérente en fonction des besoins des différents utilisateurs (on y reviendra) mais aussi et surtout de manière lisible et adaptée aux informations à mettre en avant. Niveau applicatif, cela signifie qu’il faut prendre en compte non seulement les besoins pratiques de l’utilisateur mais aussi ses contraintes : consultation depuis un écran large visible de tous dans un bureau ou bien depuis son propre smartphone d’un coup d’oeil ? etc.

Une étape cruciale

Ces métaphores parfois un peu faciles visent à vous faire comprendre que l’analyse des “données de base” est une étape cruciale dans laquelle il faut prendre un maximum d’éléments en compte, qu’ils soient déjà connus ou qu’ils soient simplement prévisibles (au service d’évolutions ultérieures…).

Les différents projets auxquels j’ai pu contribuer jusque là m’ont laissé à penser que cette étape était souvent négligée, aboutissant parfois à des non-sens voire à des dispositifs qui finissent par faire perdre du temps plutôt qu’en gagner. En effet, l’enjeu d’une bonne identification des données et de leur bonne organisation est également de permettre l’ajout d’aides diverses au service des utilisateurs pour réduire les opérations/étapes de saisie et limiter très tôt les erreurs ou possibles coquilles. Un des éléments nouveau à prendre en compte est l’essor aujourd’hui de “l’open data”, qui est une mine d’or au service de la simplification des entrées et de la validation très en amont des données, qui s’enrichit chaque jour.

Quelle organisation ces données doivent-elles avoir entre elles ?

Une fois les données “de base” identifiées, il reste naturellement à concevoir les liaisons qui vont exister entre elles, afin de répondre à plusieurs objectifs : l’organisation des données, l’ajout d’intelligence à ces données, et enfin la cohérence des données.

Illustration : une bibliothèque (Thomas Leuthard sur Flickr)

Illustration : une bibliothèque (Thomas Leuthard sur Flickr)

L’organisation des données

L’organisation des données est un élément critique lors de la conception d’une application web. En effet, il va découler des liaisons et autres contraintes choisies, un grand nombre de conséquences pratiques sur les différentes possibilités offertes par l’application, qui va ainsi apparaître plus ou moins “rigide” et plus ou moins “solide”. C’est à cet instant que l’on doit s’interroger sur ce qui est obligatoire ou non, sur l’existence de valeurs par défaut en cas d’absence d’indications contraires lors de la création d’un élément, et plus important encore sur les relations qui existent entre différents éléments de base.

Si un système a pour but de gérer des employés, il est évidemment nécessaire de prévoir leurs différents regroupements en services, en sites, en entreprises… Autant de notions qui vont avoir leurs informations propres qui seront ensuite partagées envers tous leurs membres. En effet, il peut par exemple être prévu que seuls les membres d’un service puisse accéder à une fonctionnalité spécifique… ce qui sera automatique dès le rattachement d’un employé au service concerné. De nombreux éléments fonctionnent ainsi en cascade et c’est pourquoi il est important d’y réfléchir dès le début.

Des données “intelligentes”

La gestion de données grâce à l’informatique et plus spécifiquement à des applications programmées spécifiquement est également intéressante dans la mesure où elle permet d’ajouter de “l’intelligence” aux données et c’est tout l’intérêt du développement spécifique d’une application de gestion.

En effet, il y a les données que l’on peut entrer directement dans le système, qu’il s’agisse d’une opération manuelle (saisie à l’unité, import d’un lot, etc.) ou automatisée (récupération de données depuis une source identifiée fournissant régulièrement les informations attendues). Mais il y a aussi et surtout toutes les informations que le système peut générer seul à partir de ces informations. Cela suppose évidemment de définir à l’avance les règles qui seront utilisées par le système pour aboutir à cette “plus-value” automatique. On peut penser à des calculs de délais, des statistiques, des moyennes, et à différentes indications que l’on peut obtenir facilement à différents niveaux à des fins de comparaison ou de compréhension.

Dit comme cela, ce n’est pas très concret. Mais on saisit mieux de quoi il est ici question quand on donne des exemples comme l’envoi d’un courriel automatique ou d’une notification de relance à une personne concernée par un dossier en retard. Il peut s’agir de données de contexte qui, sans saisie nécessaire, seront ajoutées automatiquement à un élément (date, taille, créateur, date de dernière mise à jour, …). Il peut s’agir de la mise en forme automatisée de certaines données se trouvant ainsi adaptées à une impression papier, à laquelle on peut ajouter des QRcode qui auront une action sur le dossier concerné lorsqu’ils seront scannés… ou à l’inverse qui permettent à partir d’un extrait de dossier de retrouver l’ensemble des données associées, etc. etc. D’un point de vue plus “pratique” si l’on imagine un restaurant qui gère une carte composée de différents menus, eux-mêmes constitués de plats… un système bien conçu permettra de mettre en regard quantité d’ingrédients nécessaires pour chaque plat en fonction du nombre de commande et des stocks disponibles… Afin d’en tirer des moyennes, voire d’avoir une estimation de la prochaine pénurie selon des règles spécifiques ou tout simplement la répartition constatée des dernières ventes projetées sur quelques jours supplémentaires dans le futur. On pourrait aussi en déduire un coût de revient par plat et donc la marge, etc.

La cohérence des données

Nous avons tous nos petites habitudes et cela peut avoir des conséquences ravageuses dans la situation où plusieurs personnes utilisent un même outil de manière totalement différente. C’est pourquoi s’assurer de la cohérence des données est indispensable et doit là aussi faire partie d’une stratégie globale réfléchie dès le début, en amont.

Il ne s’agit pas forcément de se montrer coercitif en direction des utilisateurs, mais de leur donner à utiliser des outils qui les orientent – directement par une aide à la saisie ou indirectement par des “nudges” – vers une présentation cohérente des données. Des exemples simples peuvent illustrer cette nécessité, telle que l’entrée d’un numéro de téléphone que certains écriront séparés par des points, d’autres par des tirets, d’autres encore par des espaces… Une situation pas forcément grave quand, à l’oeil nu, cela présente juste un inconfort visuel… Mais une situation bien plus dramatique quand on veut imaginer l’envoi en masse d’un SMS par exemple, et qu’un numéro sur 5 seulement est valide car présenté correctement… Et inutile de dire que des outils assez fondamentaux comme la lutte contre les doublons par exemple, sont rendus bien plus difficiles à mettre en place quand les données initiales sont “de mauvaise qualité”, en raison d’un manque de cohérence.

Autant de petits détails qui font la différence entre un outil efficace et évolutif et un outil qui ne fait que “numériser” des habitudes auparavant plus “traditionnelles” sans en profiter vraiment pour faire de cette “numérisation” du flux de travail un réelle plus-value apportant plus de confort et plus de fonctionnalités. Je dis souvent une chose simple : la modernisation d’un flux de travail via les outils numériques doit aboutir à plus de simplicité, à moins d’opérations rébarbatives et à plus de potentialités au niveau des informations facilement accessibles. Dans le cas contraire, il n’y aura aucun enthousiasme face au changement, et pire… les personnes concernées n’y verront aucun intérêt, ce qui est loin d’être une situation qui stimule l’efficacité et l’envie d’avancer collectivement dans une évolution commune.

Quelles sont les différentes personnes qui vont utiliser les données ?

Là encore, la question est fondamentale en raison du caractère “sur-mesure” que permet la conception d’une application web.

Illustration : personne derrière un ordinateur (iAdvise sur Flickr)

Illustration : personne derrière un ordinateur (iAdvise sur Flickr)

Au départ : un manque de cohérence

En effet, le point de départ qui fait ressentir le besoin d’un développement spécifique est souvent un constat qui revient souvent : plusieurs personnes travaillent “sur” les mêmes informations mais avec des besoins et des questionnements différents… et donc des présentations différentes. C’est précisément ce qui génère des doublons, du travail répété inutilement voire une inefficacité globale chronique.

L’un des exemples que j’ai pu rencontrer concerne un flux de “traitement de dossier” tout ce qu’il y a de plus banal, les différentes étapes étant éclatées entre différentes personnes. Sauf que confrontée à des besoins spécifiques, chacune avait développé des stratégies personnelles qui montrent vite leurs limites. C’est ainsi que l’on pouvait trouver le dossier initial rangé dans un classeur trié par nom du demandeur, mais aussi une “copie de travail” du dossier qui était celle qui circulait de personne en personne afin de le traiter (finissant généralement recouverte de post-its griffonnés à la hâte), mais encore d’une liste récapitulative des dossiers saisie dans un tableur Excel de manière chronologique mise à jour en même temps que le dossier original du classeur d’arrivée afin d’indiquer par exemple qui avait été désigné pilote, puis, plus tard, si le dossier était clôturé… Ce qui laisse imaginer le nombre de manipulations nécessaires à chaque étape, à la condition bien sûr que le pilote pense bien à prévenir “l’origine” de l’avancée du dossier, et que tout soit bien mis à jour en même temps dans les multiples endroits évoquant le dossier concerné. Enfin je ne veux pas être trop long sur cet exemple mais il faudrait ajouter que selon le “canal d’arrivée” d’un dossier (téléphone, sur place, par courrier…) des outils différents se trouvent utilisés, chacun avec ses spécificités et ses contraintes.

Bilan ? L’impossibilité quasi certaine de tenir à jour toutes les données nécessaires à chaque endroit qui le nécessite… Un casse-tête quand il s’agit de savoir rapidement où en est un dossier particulier… Une totale absence de visibilité de la part de la hiérarchie pour avoir une idée rapide du nombre de dossiers en attente et de la charge de travail des différentes personnes en charge d’y répondre… et un archivage sous forme de casse-tête, l’ensemble des éléments d’un même dossier n’étant, finalement, jamais réuni en un même endroit. S’y ajoute le fait qu’une même personne faisant plusieurs demandes ne voit aucun rapprochement opéré entre ses différentes sollicitations si elles terminent vers des personnes différentes, ce qui peut être un gage de dysfonctionnement et dans tous les cas d’un manque d’information de contexte.

Penser avant tout aux besoins des utilisateurs

Pour répondre à ces défis, il est nécessaire de penser avant tout aux besoins des utilisateurs, qui sont nécessairement en cohérence avec les spécificités qui leur incombent face à une tâche précise. C’est cette prise en compte toute simple qui va apporter la description d’une bonne partie des fonctions de l’application web que l’on cherche à mettre en place.

Si l’on reprend les grandes lignes de l’exemple précédent, il va falloir différencier les tâches de recherche/création (saisie des informations de base ou recherche rapide d’indication sur l’avancée d’un dossier en cours), de pilotage (tableau de bord des éléments voire possibilité d’affecter les éléments nouveaux à telle ou telle autre personne), de résolution (collecte progressive d’informations, puis aboutissement à une solution qu’il faut éventuellement faire valider), et de clôture (envoi de la réponse définitive et archivage du dossier pour mémoire).

Cela permet de se rendre facilement compte que tout le monde travaille en fait sur les mêmes informations, mais ce qui va changer radicalement sera le niveau de détail dans l’accès à l’information, la présentation de cette information au regard des objectifs différents qui sont ceux de chaque utilisateur, les possibilités de compléments, et les possibilités d’interaction avec l’information qui seront différentes en fonction du rôle de chacun. Il est donc assez simple d’arriver au final à un outil sur-mesure qui ne nécessite pas l’alimentation manuelle de plusieurs outils distincts et sans lien entre eux… Outil qui se trouve toujours “à jour” des dernières informations disponibles à chaque consultation, et qui ajoute de l’intelligence aux données présentes dans le système grâce aux mécanismes de pilotage, de validation, d’alerte, de recherche, etc. qui sont associés.

Il faut donc réfléchir aux besoins qui sont communs (fonctionnalités offertes à tous les utilisateurs) et aux besoins qui sont spécifiques (fonctionnalités restreintes ou contrôle du niveau d’information fourni). Pour chaque métier ou chaque rôle spécifique tenu par un utilisateur dans un flux de travail donné, il va donc en résulter un ensemble outils (saisie, recherche, …) / présentations (unitaire, en lot, tableau de bord, …) / et actions attendues (validation, affectation, import, export, …).  

Quel est le “flux” de travail que l’on veut traduire numériquement ?

On déduit facilement du point précédent qu’au-delà du rôle de chaque utilisateur dans le traitement d’une tâche en particulier, c’est la totalité du “flux” de travail qui se trouve interrogée. Et c’est un domaine pour lequel il convient de réfléchir parfois sous un angle nouveau, un des pièges classiques étant de simplement chercher à rendre “numérisée” la technique de travail “présente” en ne faisant que copier/coller l’organisation telle qu’elle existe sur des outils nouveaux.

Parfois, la nuance est subtile mais elle prend tout son sens à la lumière du côté pratique qu’elle permet – ou pas – à un utilisateur. Pour prendre un exemple très classique, il est probable qu’une organisation dotée de secrétariats cherchent à moderniser le “post-it” habituel que l’on griffonne à la hâte quand un coup de fil arrive avant d’aller le déposer sur un coin de bureau de son chef pour le lui faire savoir.

Une des réactions possibles – je l’ai déjà observée – est de prévoir un modèle tout prêt de courriel intégré à Outlook de sorte à proposer au secrétaire qui reçoit le coup de fil une version numérisée de sa note de message en un clic. C’est pratique car c’est accessible en un clic. C’est plus lisible car dactylographié au lieu d’être griffonné. C’est moderne car au lieu d’encombrer le bureau de son chef, cela encombre plutôt sa boite mail… par ailleurs déjà bien pleine !

Hé bien ce type de réaction correspond selon moi à ce qui ne faut surtout pas faire. Pourquoi ? Car on ne fait que transposer à l’outil numérique un outil papier, ce qui “fait moderne” mais n’apporte absolument aucune plus value si ce n’est le caractère plus lisible du message ainsi transmis. Est-ce que cela simplifie la vie de son destinataire : non. Est-ce que cela améliore l’opération de saisie qui incombe au secrétaire : non. Est-ce que cela apporte de l’intelligence aux données saisies : non. Cela ne permet même pas d’obtenir facilement une liste des messages ainsi transmis, par exemple un récapitulatif en fin de journée.

Si on imagine cette fois la même tâche, vue sous l’angle d’un outil plus intégré… les choses peuvent devenir beaucoup plus intéressantes, tant pour le secrétaire que pour son chef. Ainsi, la première information que l’on peut demander en saisie est un numéro de téléphone. Là, un système intelligent peut immédiatement afficher les informations déjà connues qui s’y rattachent, ou proposer de créer (ou simplement d’ajouter ou corriger) des informations. La personne au bout du fil pourrait apprécier de voir que son interlocuteur sait si elle a déjà appelé, si oui quand, voire éventuellement pourquoi. Une fois sa demande saisie, celle-ci peut alors être affichée dans un tableau de bord adapté que le “chef” peut avoir pour lister les différentes sollicitations qu’il a reçues, triées par type (téléphone, …) ou selon d’autres critères dont il convient avec son secrétaire (niveau d’urgence, catégories, …). On peut alors imaginer que ce message puisse être fourni à un subordonné pour suites à donner en 2 clics, ou toute autre procédure identifiée comme étant commune dans l’organisation du travail que l’on cherche à moderniser. On peut également considérer ce message comme une “pièce supplémentaire” d’un puzzle plus grand, qui rassemblerait par exemple tous les éléments concernant un dossier particulier, dont ce message, afin d’en conserver un détail complet et un historique global.

Évidemment il s’agit là d’un exemple simple, presque trivial. Mais il est à mon sens quelque chose d’intéressant dans la mesure où il permet bien de faire la différence entre deux approches très éloignées, avec in fine des objectifs très différents. Pour des flux de travail bien plus complexes que la simple saisie d’un message téléphonique, il est clair qu’une démarche intégrée apparaît bien plus intéressante qu’une simple “numérisation de l’existant”, d’autant plus si l’outil est construit sur une logique modulaire et peu à peu extensible… La dactylographie d’éléments qu’on imprime ou envoie sans réutilisation intelligente est donc le symbole même de ce qui est à bannir, car elle ne donne absolument aucun plus-value à l’opération de saisie… déjà bien assez rébarbative !

Quelles sont les différentes formes “finales” que l’on cherche à obtenir ?

C’est une approche qui n’est pas contradictoire avec l’ensemble de ce que l’on a vu jusqu’à présent, et qu’il faut toujours prendre en compte même quand on “part de la fin”. Cette approche consiste simplement en une question simple, même s’il faut parfois la détailler pour la cerner complètement : qu’aimeriez-vous avoir et sous quelle forme pour que votre travail (ou en tout cas ce qui l’entoure) soit plus facile ?

Illustration : un cockpit de Concorde (Rob Alter sur Flickr)

Illustration : un cockpit de Concorde (Rob Alter sur Flickr)

Si la question est simple, la réponse est compliquée dans le sens où les futurs utilisateurs de l’application n’ont parfois aucune idée des possibilités techniques qui sont celles que l’on peut atteindre par une programmation adaptée. Si vous parlez à un manageur habitué à un “tableau de bord” A4 mensuel sur papier qui n’est qu’une compilation d’extraits de tableaux Excel aux proportions déformées par les copiers/collers et de graphiques plus ou moins lisibles… il va avoir du mal à imaginer que l’ensemble de ces informations peut se retrouver sur un tableau de bord bien plus fonctionnel, mis à jour en temps réel, avec des graphiques interactifs, et la possibilité en un clic d’afficher le détail de n’importe quelle donnée synthétique qui lui est présentée… De même, le responsable habitué à un état des lieux présenté sous la forme d’une liste remise sur papier lors d’une réunion hebdomadaire aura du mal à l’envisager à disposition en permanence, mise à jour, avec codes couleurs et évolution automatisée en fonction d’un contexte toujours changeant. Enfin, pour en terminer avec ce type d’exemple, il est évident qu’un directeur ne pourra pas imaginer avoir sous les yeux des statistiques précises capables de l’aider dans ses choix si ce sont des informations qui ne sont pas disponibles jusque là (ou qui ne le sont que difficilement), par exemple la charge de travail de collaborateurs qui peuvent l’inciter à épargner un surchargé ou à le renforcer pour mieux affronter un pic d’activités…

Une chose est sûre, l’intérêt majeur d’une application spécifique est de permettre de générer presque autant de “visualisations” différentes des données contenues dans le système ou calculées par lui que l’on souhaite, sans que cela ne nécessite un autre travail que la conception initiale de ces différentes vues. Une fois mises en place, celles-ci sont automatiquement mises à jour en temps réel, et peuvent remplir leur office au quotidien sans qu’il soit nécessaire de les construire manuellement, comme c’est malheureusement encore trop souvent le cas. Quand au sein d’une organisation on se rend compte qu’une même information doit être saisie plusieurs fois à plusieurs endroits (ou sous plusieurs formes) différent(e)s… il est temps de s’interroger !

Conclusion

Le but de cette première et rapide approche de la réflexion entourant la conception d’une application web spécifique en vue d’usages précis, notamment professionnels, est de vous montrer qu’il s’agit d’une occasion souvent simple de réinterroger des méthodes de travail souvent complexes. Se poser les bonnes questions en amont permet d’éviter bien des déceptions par la suite, surtout si cela permet concrètement de simplifier la vie des utilisateurs en “bout de chaîne” et d’apporter des fonctionnalités et informations supplémentaires à ceux qui en ont besoin.

Il s’agit là d’un préalable indispensable à la mise en place, par la suite, d’outils et services innovants. On peut par exemple imaginer qu’un demandeur muni d’un simple numéro de dossier et de son nom puisse consulter l’avancée du traitement de son propre dossier (même s’il n’en voit évidemment pas tous les détails). On peut imaginer une interconnexion ou un enrichissement de dossiers dans une logique modulaire où des informations de “base” sont partagées et sont complétées d’informations complémentaires dont seule une partie est partagée… Rendant ainsi n’importe quel utilisateur en capacité de renseigner sur l’avancée d’un dossier et sur les services saisis sans pour autant donner des détails excédentaires à des personnes n’ayant pas besoin d’en connaître. On peut imaginer enfin une procédure spécifique lors de la clôture d’un dossier qui permet d’assurer une sauvegarde complète de tous ses éléments pour archivage numérique, réunis dans un seul et même dossier informatisé. Les possibilités sont… très vastes.

Si je devais faire passer un message unique à la suite de cette présentation un peu rapide, ce serait celui-ci : voyez vos données des fondations, des ponts, les ingrédients de base de recettes bien plus élaborées… sans jamais casser le lien qui existe entre la donnée de base et le résultat final. Ainsi, lorsque la donnée sera modifiée à la base, toute la chaîne pourra être mise à jour de manière intelligente ce qui pourra profiter à tous ceux qui en sont les acteurs, quel que soit le maillon de la chaîne où il se trouve. Vous ouvrirez ainsi la voie à des systèmes à votre service, qui seront des appuis et non des contraintes, et qui vous permettront avec souplesse d’innover au service du confort des utilisateurs et de vos clients éventuels !

Je reste naturellement ouvert à toute suggestion, remarque ou même à toute information complémentaire que vous trouveriez adaptée !