Article écrit par Vincent Luycx
Le processus de conception d’une application web est très varié alliant des compétences très diverses et peut selon le périmètre de l’application visée faire intervenir plus d’une dizaine de compétences très différentes c’est ce que nous vous proposons de décrire ci-dessous.
L’ensemble de ces éléments peut être vu comme une checklist permettant de s’interroger sur la complétude de son approche dans la conception et la réussite de son projet d’application web.
Nous vous proposons dans cet article un processus complet qui vise à prendre en compte toutes les étapes clés de votre projet d’application web. Le lecteur averti et expérimenté choisira de déléguer tout ou partie de ces étapes vers son ou ses partenaires mais gardera à l’esprit le besoin de contrôle sur ces différents instants du cycle de vie du projet à naître.
Par où commencer ?
La première des questions à se poser consiste à repartir de l’existant ; l’application web visée est-elle l’amélioration d’une application existante ou bien s’agit-il de repartir d’une page blanche ?
Les problématiques opérationnelles seront tout à fait différentes selon le cas ; il faudra ou non penser dès l’initialisation du projet à la migration de données existantes ou de base d’utilisateurs identifier les impacts en termes de disponibilité…
- Quels seront ensuite les éléments majeurs ou différenciants de cette nouvelle application ?
- Quel positionnement adopter face à la concurrence ?
La stratégie de positionnement sera essentielle notamment concernant les attentes des futurs utilisateurs de celle-ci la stratégie de référencement le style de communication…
Afin de répondre à ces premiers enjeux primordiaux une technique pertinente consiste à faire appel aux techniques de co-design de “design thinking” de “business canvas” ou toute stratégie globale permettant de repositionner son projet dans un ensemble cohérent avec la stratégie de l’entreprise.
Commençons par renoncer… pour mieux se projeter !
Une fois ce positionnement clair la seconde étape consiste à définir les fonctions majeures souhaitées de définir la roadmap globale de l’application afin de prendre les bonnes orientations dès l’initialisation de la plateforme et éclairer les futurs choix à l’aune de la projection de l’application.
Après avoir déterminé les grandes fonctionnalités de l’application viendra un temps essentiel de concentration des efforts (financiers matériels et planning) pour définir ce qui consistera la version initiale de la plateforme en définissant le MVP “Minimum Viable Product” ; il s’agit là d’une étape essentielle à plusieurs titres :
- Arriver à se projeter rapidement sur le marché dans les mains des utilisateurs
- Se mettre dans une posture “test and learn” et chercher du retour sur investissement en concentrant les efforts de l’ensemble des intervenants sur un futur si pas idéal au moins proche et matérialisé
La culture du MVP est parfois ressentie comme la culture du renoncement mais de notre expérience il s’agit là d’une étape essentielle de conception et d’anticipation de ce que sera l’application dans des conditions réelles. La prise de risque associée est également limitée par une approche de ce type.
Une des dimensions à aborder dans la définition de ce MVP concerne le choix de la future audience de cette application qui permettra de définir la criticité des éléments clés (UX design sécurité…).
L’application se montrera sous un jour différent selon qu’elle est destinée à des utilisateurs en mode B2C B2B ou encore si la volonté est d’exposer les services de l’application via APIs publiques ou authentifiées.
L’importance des besoins non fonctionnels
Une fois une roadmap claire avec des fonctionnalités essentielles (définies ou non sous forme de use cases évaluées par une méthode de type MoSCoW) il conviendra de se positionner dès le début du projet sur les éléments non fonctionnels qui peuvent avoir trait à des univers très différents : quel est l’impact du time to market les éléments de sécurité sont-ils essentiels (dépendant fortement des données à manipuler cfr RGDP DSP2 ou autre référentiel réglementaire au-delà d’une due diligence cohérente avec les meilleures pratiques du marché sur les aspects standards de sécurité type OWASP).
Selon le positionnement choisi il conviendra de rapidement s’intéresser aux éléments de volumétries attendues (nombre de connexions quantités d’informations type images ou fichiers à échanger) à l’importance de l’UX (selon le type d’audience visée) le besoin ou non d’être autonome quant à l’évolutivité du contenu mis en ligne par le biais de CMS “Content Management System”.
Une application dans un écosystème
Une fois les éléments fonctionnels et non fonctionnels définis et à ce stade aucune ligne de code n’a encore été écrite il convient de réfléchir à la stratégie de référencement SEO “Search Engine Optimisation” en identifiant les contenus clés et différenciants de cette application web les besoins ou non de partage sur les réseaux sociaux en un mot la gestion du trafic à venir sur l’application et comment celui-ci sera mesuré suivi et géré.
L’application sera-t-elle ouverte vers l’extérieur (publication de contenus externes avec éventuels copyright besoin de modération du contenu de double validation…) ; selon le cas les impacts sur l’architecture de l’application seront critiques.
Identité visuelle
Dans notre voyage au sein du processus de conception d’une application web nous avons désormais atteint le besoin d’identité visuelle qui passera par la définition de l’UI “User Interface” l’identité de la marque à véhiculer la charte graphique à définir ou à suivre les éléments de graphisme à mettre en œuvre la cohérence visuelle globale de l’application dans ses différentes composantes la particularisation de l’univers visuel selon la typologie d’utilisateur et tout élément qui permettra de se différencier et aider à l’usage de cette application.
Après l’identité visuelle vient la création du contenu ; il est essentiel d’avoir une idée claire du contenu à mettre en œuvre qui permet un réel gain de temps de mise en œuvre par la suite. Quelles infographies mettre en avant quelles photos quel ton rédactionnel déployer selon la proximité recherchée avec les utilisateurs de l’application.
Une fois l’ensemble de ces dimensions abordées ou pour certaines écartées en toute connaissance et responsabilité les étapes suivantes entrent plus classiquement dans les éléments attendus en termes de conception et réalisation. Voyons ensemble ces prochaines étapes.
UX design ergonomie
L’étape suivante concerne l’architecture de l’application quels seront les contenus à favoriser selon l’audience visée quelle stratégie multi-device déployer (besoin de viser des tablettes mobiles ? Via des applications dédiées tirant parti spécifique de ces devices ou uniquement via du “responsive design” ?).
Selon la stratégie choisie l’application web verra la naissance de ses petites sœurs sur dispositifs mobiles avec leurs propres besoins et les étapes de cet article pourront grandement être reprises pour définir comment les construire.
À l’instar des étapes de “design thinking” évoquées plus haut un très bon outil permettant de se projeter avant réalisation consiste à la création de maquettes.
Celles-ci permettent à moindres frais et dans un contexte libre de faire des essais de projeter une vision des briques essentielles évoquées ci-dessus (design UX graphisme identité de marque…). Ceci permet de tester au plus tôt différentes orientations de procéder à des tests utilisateurs sur la pertinence de certains choix ou orientations et de valider l’adéquation des contenus proposés.
Le cadre de l’application a été défini son audience rêvée également nous aurons défini les fonctionnalités majeures à mettre en avant dans un mode particulier pour l’audience visée en ayant pris en compte des besoins non fonctionnels pour garantir un usage sans heurt auprès des futurs clients il est temps enfin de parler des besoins techniques de la future application dont les pré-requis auront été définis grâce à notre cheminement par les questions ouvertes ci-dessus.
Architecture sécurité DevOps frameworks : le mix gagnant !
Quelle architecture mettre en œuvre pour l’application ; celle-ci sera très différente selon la typologie d’application les volumétries la sécurité l’ouverture à l’extérieur les supports utilisés les objets à manipuler…
Il est loin le temps du développement d’applications web avec le bloc-notes ; désormais toute application web de par sa richesse est avant tout une construction de modules (authentification suivi analytique paiements communication CRM “Customer relationship Management)…
Votre partenaire sera force de proposition pour vous accompagner ou vous proposer des choix pertinents dans le contexte spécifique de l’application.
- Quels seront alors les langages de programmation à utiliser les “frameworks” choisis ?
- Comment se projeter sur les cycles de vie de ces derniers selon que les choix se portent sur des technologies émergentes non matures ou plutôt sur des technologies mainstream mais peut-être plus limitées en termes d’UX de fonctionnalités ?
Les choix technologiques peuvent ou non faire partie des choix et partis pris avant démarrage des travaux de conception de l’application ; il conviendra de s’interroger sur la disponibilité des ressources aptes à déployer ces technologies la qualité de celles-ci et la complexité à monter des équipes le cas échéant.
En lien avec l’architecture et la stack technique une dimension à étudier concerne la partie DevOps ; articulation entre les développements et les opérations (déploiement maintenance support hébergement infogérance…).
L’infrastructure fait partie intégrante d’un projet de conception d’application Web souvent parent pauvre des réflexions soit par manque d’intérêt ou de connaissances mais maillon essentiel dans le succès d’une application web ; quelle criticité attendue pour l’application quels mécanismes de résistance à la panne mettre en œuvre comment outiller un DRP “Disaster Recovery Process” afin qu’il soit le plus transparent possible comment mesurer la disponibilité de l’application la monitorer suivre des indicateurs du type MTTR “Mean-time to repair”?
Ces étapes préliminaires ne sont pas toutes obligatoires mais se poser les bonnes questions avant de démarrer les travaux de réalisation fait immanquablement gagner du temps par la suite. Selon les affinités de chacun plus ou moins de temps sera consacré à chacune de ces étapes.
Animation du projet début des travaux
Selon la taille et la complexité de l’application web à concevoir l’équipe à constituer pluridisciplinaire sera à géométrie variable. Il faudra animer cette équipe en choisissant les meilleures techniques qu’il s’agisse ou non de méthodes agiles de cycle waterfall il n’y a à ce stade pas de mauvaise option il suffit d’être à l’aise avec les choix et partis pris.
Comment assurer le suivi des développements quel est le niveau d’implication souhaité par le commanditaire quelle latitude de délégation sur la mise en œuvre ?
Qualité de la production logicielle
L’équipe technique aura à cœur de gérer le cycle de développement de cette application en déterminant le mode de gestion des sources applicatives (génération automatique et régulière des packages applicatifs) le type de déploiement attendu (continu ou non) la stratégie de versionnage (très impactante pour les utilisateurs une fois une première version accessible en production et encore plus critique a fortiori pour des applications exposées via APIs).
L’équipe aura pleinement conscience qu’elle n’est qu’intermédiaire dans la mise en œuvre même si la relation avec le commanditaire vous est prévue pour durer. De ce fait l’équipe sera particulièrement diligente sur la documentation du code la qualimétrie de celui-ci suivra l’éventuelle dette technique s’assurera de la dépendance avec des sources externes sera force de proposition quant à la veille sur les éléments essentiels de ces produits externes (roadmaps gestion des éventuelles failles de sécurité…).
Le processus de mise en œuvre du code de l’application devra prendre en compte les meilleures pratiques en termes d’automatisation de tests (outil essentiel au déploiement continu) devra s’assurer de l’adéquation avec les besoins non fonctionnels exprimés (volumétries réactivité…) et permettre aux utilisateurs finaux de réceptionner les développements réalisés dans les meilleures conditions.
C’est également à ce niveau que les ressources DevOps apporteront leur concours dans la gestion des environnements hors production permettant d’en dédier certains à du test utilisateur de la formation des tests techniques…
Et après ?
Avant tout déploiement vers les utilisateurs finaux et de façon régulière les dernières étapes ci-dessous nous semblent également pertinentes afin de garantir la pérennité de l’application web et de l’ensemble des efforts qui auront été déployés pour la faire naître.
Nous recommandons l’exécution régulière de tests de performance et de tests de pénétration ; les besoins sur ces dimensions évoluent au fil du temps et de l’usage de l’application.
Comme évoqué plus haut une veille particulière doit être mise en place sur les frameworks et langages utilisés sur les composants outillant l’infrastructure hôte sur la surveillance de la sécurité de l’application comme le cycle de vie des certificats par exemple.
La délégation n’exclut pas le contrôle
Nous avons dans cet article souhaité vous éclairer sur le processus de conception d’une application web en décrivant les étapes qui nous semblaient les plus pertinentes et essentielles sur lesquelles s’interroger et surtout interroger votre futur partenaire de développement. N’hésitez pas à nous partager vos propres retours d’expérience nous sommes toujours prêts à échanger.