Comment architecturer une application en respectant les ambitions et contraintes des différents intervenants d’un projet ?
Architecturer une application est une activité qui requiert des connaissances globales et générales dans l’informatique conséquentes. Il faut connaître les structures, les ressources et les technologies que l’on peut attribuer à un projet. Mais on doit également savoir si l’équipe avec laquelle on travaille maîtrise les technologies ou les ressources que l’on souhaite utiliser.
C’est quoi une application ?
Une application est un programme ou un ensemble de logiciels destinés à réaliser une tâche ou un ensemble de tâches élémentaires d’un même domaine.
Une application permet de résoudre une problématique précise, elle a été conçue dans ce but. Elle correspond souvent à un corps de métier.
On retrouve principalement deux types d’applications : les applications web et les applications mobiles. La principale différence entre ces deux types d’application sont les supports sur lesquels elles vont être utilisées. Par exemple, comme leur nom l’indique, une application mobile sera installée puis utilisée depuis un téléphone.
Une application web, quant à elle, sera utilisée depuis n’importe quel navigateur web. On peut utiliser une application web depuis un navigateur sur un ordinateur (PC / Mac) mais également via un navigateur sur le smartphone. Souvent, les applications web et mobile interrogent les mêmes serveurs (API) pour éviter de doubler la quantité de travail côté back-end. ⚠️ Mais attention car ce n’est pas systématique.
Voici un schéma global simplifié d’une architecture d’application, comprenant également son interaction avec les serveurs. On imagine ici un utilisateur et une application web/mobile standard.
Comment ça fonctionne ?
Un de mes professeurs nous répétait souvent :
“Un site web c’est comme un bar.”
On ne comprenait pas vraiment comment ni pourquoi jusqu’à ce qu’il nous montre son illustration. C’est en réalité une très bonne analogie qui représente le fonctionnement d’un serveur web.
Comment est architecturée une application ?
L’architecture d’une application est le résultat d’un long travail de définition qui répond aux contraintes techniques et aux besoins client.
Conception d’une solution
- Le client possède un cahier des charges.
Dans le cas où le cahier des charges serait déjà existant, il reste soit à le compléter soit à directement commencer le projet. Selon la qualité du cahier des charges fourni, il y a tout de même une phase d’analyse de celui-ci. Il faut analyser le cahier des charges existant pour vérifier si notre équipe technique est capable de réaliser ce projet.
- Concevoir le cahier des charges
Le cahier des charges a pour but de définir le projet en détail en listant toutes les contraintes et attentes du projet.
Le processus d’élaboration d’un cahier des charges est un cycle et comporte quatre activités :
Le recueil : rechercher les besoins et favoriser leur expressionL'analyse : prioriser les exigences et maintenir leur cohérenceLa spécification : décrire et documenter les exigencesLa validation : obtenir un accord sur les exigences spécifiées
Le résultat de l’exercice du cahier des charges permet la validation des besoins client et la définition de la solution.
Utilisateurs
L’utilisateur est un élément important dans le processus d’architecture d’une application. L’application va être conçue selon l’utilisateur cible. Il y a plusieurs paramètres à prendre en compte comme la moyenne d’âge des utilisateurs, le type d’utilisateur, le nombre d’utilisateurs. Il faut définir clairement notre cible utilisateur afin d’avoir un maximum d’efficacité.
Interfaces
La réalisation des interfaces est découpée en deux parties. Tout d’abord, il y a la phase de conception par les UI/UX designers. Ils sont chargés de réaliser des maquettes du produit. Les interfaces doivent correspondre à l’attente et au besoin du client. Elles devront aussi correspondre à la charte graphique de l’entreprise ou du projet client. Une fois cette phase de conception terminée, il y a la phase d’intégration qui se résout par l’exercice de convertir ces prototypes en véritable page web via l’utilisation de framework JavaScript notamment.
Les interfaces utilisateurs web sont régulièrement réalisées avec un framework JavaScript afin de rendre industriel le développement de cette interface. L’industrialisation du développement d’une application fait référence notamment à la possibilité de créer des composants réutilisables, de factoriser du code, d’utiliser des design patterns et mettre en place toute une organisation de développement du produit final.
L’interface est une partie importante qui sera le véritable produit disponible pour le client. Ainsi, l’image qu’il dégagera sera interprétable par les clients comme véritable image de marque ou d’entreprise. Il est donc très important d’avoir une interface utile avec une bonne expérience utilisateur.
Code
API
Une API, ou Interface de Programmation d’Application, est un ensemble normalisé de classes, de méthodes, de fonctions et de constantes qui servent de façade, par laquelle un logiciel offre des services à d’autres logiciels.
Une API permet à différents appareils de venir interroger le back-end et donc de simplifier la partie serveur en proposant le même service.
L’API définit la façon avec laquelle on va communiquer avec le serveur. On peut très bien avoir une API qui est architecturée en microservice et en monolithique.
Architecture d’application
De nos jours, il y a deux concepts d’architecture back-end d’application populaire. Le monolithique et les microservices.
Monolithique
Les applications monolithiques dominent aujourd’hui le domaine du web. En effet, la plupart des sites web sont des applications monolithiques. Wordpress est un exemple d’application monolithique.
Une application monolithique est une application logicielle qui est conçue comme une seule et unique unité de code. Cela signifie que toutes les fonctionnalités de l’application sont regroupées dans un seul et même programme, qui est compilé et exécuté en tant qu’application autonome. Les applications monolithiques sont souvent développées en utilisant un seul langage de programmation et une seule base de données. Elles sont généralement conçues comme une solution unique pour un problème spécifique.
Les applications monolithiques peuvent être avantageuses en raison de leur simplicité et de leur facilité de déploiement et de maintenance. Cependant, elles peuvent également être plus difficiles à mettre à l’échelle et à maintenir lorsque l’application grandit et devient complexe.
Par conséquent, de nombreux développeurs choisissent des architectures d’applications modernes telles que les architectures orientées services, qui offrent une plus grande flexibilité et une meilleure capacité à s’adapter.
Microservices
Microservices
Les microservices sont une technique de développement logiciel. Il s’agit d’une variante du style architectural de l’architecture orientée services (SOA) — qui structure une application comme un ensemble de services faiblement couplés. Les microservices indépendants communiquent les uns avec les autres en utilisant des API indépendantes du langage de programmation.
Des API REST sont souvent employées pour relier chaque microservice aux autres. Un des avantages est que lors d’un besoin critique de mise à jour d’une ressource, seul le microservice contenant cette ressource sera mis à jour. L’ensemble de l’application restant compatible avec la modification, contrairement à la totalité de l’application dans une architecture classique. Cependant, le coût de mise en place, en raison des compétences requises, est parfois plus élevé.
Architecture orientée services
L’architecture orientée services (SOA) combine ces deux approches. Elle offre une mise en œuvre et une maintenance plus abordables comme dans l’architecture monolithique, mais elle permet également de déléguer les processus lourds nécessitant des calculs ou des traitements à un service externe. Cela signifie que certaines parties de l’application peuvent être exécutées sur un serveur externe, au besoin, pour améliorer les performances et assurer la scalabilité.
En résumé, l’architecture orientée services est une approche qui vise à simplifier le développement et la maintenance des applications en combinant les avantages de l’architecture monolithique et des microservices.
Serveurs
La partie serveur peut énormément varier selon le besoin de l’application ou l’architecture de celle-ci.
Les serveurs sont généralement loués via des hébergeurs. Sauf pour des cas précis où on souhaitera posséder des serveurs physiquement pour avoir un contrôle absolu dessus ou par soucis de confidentialité.
Les différents et nombreux aspects de la partie serveur d’une application définissent une dynamique d’apprentissage constant. Les architectes doivent être maintenu à jour sur ce qui se fait en matière d’architecture et de déploiement.
Le nombre de serveurs d’une application peut varier selon la charge qu’il va subir et selon la scalabilité que l’on souhaite apporter à notre application ou notre architecture.
Un site web peut très bien être composé d’un seul serveur comme un site vitrine ou avec des milliers à l’image de Netflix ou Twitter.
Base de données
“Et ma data ? J’en fais quoi ?”
Une base de données permet de stocker et de retrouver des données structurées, semi-structurées, brutes ou bien de l’information, souvent en rapport avec un thème ou une activité, celles-ci peuvent être de natures différentes et plus ou moins reliées entre elles.
La base de données est un élément clé d’une application. C’est elle qui va stocker, gérer et distribuer les données qu’elle stock. Il est important qu’elle soit toujours vraie, à jour et qu’elle possède des sauvegardes de différents états à différents moments (Une, deux ou trois sauvegardes par jour ou par semaine).
La base de données peut être choisi selon plusieurs contraintes :
- Besoin relationnel.
- Accessibilité de la donnée.
- Supporter la montée en charge.
- Respect des propriétés ACID (atomicité, cohérence, isolation et durabilité). Celles-ci sont un ensemble de propriétés qui garantissent qu’une transaction informatique est exécutée de façon fiable.
On choisira à partir de ces points si on opte pour une base de données Sql ou NoSql.
La différence importante entre le Sql et le NoSql.
“NoSQL signifie à la fois « Not only SQL », car certains langages NoSQL comprennent le langage SQL en plus de leur propre capacité, et « Non-relationnel » parce qu’il ne peut pas stocker facilement des données relationnelles.”
SQL et NoSQL : Quelle est la différence et lequel choisir ?
Déploiement
Le déploiement d’une application consiste à mettre cette application en production, c’est-à-dire à la rendre disponible pour être utilisée par les utilisateurs finaux.
Le déploiement d’une application peut être un processus complexe qui implique plusieurs étapes, telles que le développement de l’application, les tests et la validation, la mise en place de l’infrastructure de déploiement et la configuration de l’application.
Il est important de bien planifier le déploiement d’une application et de mettre en place du déploiement / intégration continue dès le début du projet, pour s’assurer que celui-ci peut être fait régulièrement, de manière automatique pour éviter les erreurs humaines et si possible sans intéruption de service. Ces derniers s’appuient sur des technologies comme Gitlab CI/CD, docker et kubernetes, ainsi que la mise en place de migration de données afin de gérer les applications et leurs données de manière rapide et fiable.
Le déploiement d’une application est une étape cruciale du cycle de vie d’un projet de développement logiciel, car c’est à ce moment que l’application est rendue disponible pour être utilisée par les utilisateurs finaux. En résumé, le déploiement d’une application consiste à mettre en production cette application afin qu’elle soit utilisable par les utilisateurs finaux.
Conteneurisation
Docker et Kubernetes sont des outils qui permettent de déployer et de gérer des applications de manière efficace et flexible.
Docker est un outil de containérisation qui permet de regrouper une application et toutes les ressources dont elle a besoin (bibliothèques, dépendances, etc.) dans un conteneur. Cela permet de simplifier le déploiement de l’application en la rendant indépendante de l’environnement de déploiement.
Kubernetes, quant à lui, est un outil de gestion de conteneurs qui permet de déployer, de gérer et de mettre à l’échelle des applications containérisées de manière automatisée. Il offre une solution de haute disponibilité et de gestion de la charge pour les applications containérisées, en permettant notamment de redémarrer automatiquement les conteneurs en cas de panne ou de surcharge.
En utilisant Docker et Kubernetes ensemble, il est possible de déployer une application de manière rapide et fiable, en s’assurant que celle-ci est exécutée de manière optimale dans n’importe quel environnement.
Docker permet de regrouper une application et ses dépendances dans un conteneur, tandis que Kubernetes permet de déployer, de gérer et de mettre à l’échelle ces conteneurs de manière automatisée.
Équilibrage de la charge
La partie déploiement regroupe aussi l’aspect équilibrage de la charge et montée en charge de l’application. Dans les faits si notre application doit subir des grosses montées en charge notamment avec par exemple des pics de connexion à certaines heures. Il est nécessaire de mettre en place un système d’équilibrage de charge. Cela permettra de répartir la charge serveur en déployant plusieurs instances du même serveur en même temps afin de gérer toutes les requêtes sans perdre en fluidité ni en temps de latence et permet également d’éviter les crash en saturant un serveur de requête.
Quels sont les contraintes et les ambitions des intervenants ?
Les contraintes et les ambitions des intervenants sont assez diverses et dépendent réellement du métier et du besoin de celui-ci. Prenons des exemples.
Commercial
→ Comprendre les enjeux, attentes et objectifs du client
→ Coordonner les différents experts internes pour imaginer la réponse optimale
→ Budgétiser et presenter l’approche et la solution au client
→ Suivi de la relation client
Chef de projet
→ Satisfaction client.
→ Respect du cahier des charges.
→ S’assurer du respect des temps de développement pour effectuer des livrables.
→ Respect des contraintes globales de chaque membre de l’équipe.
Designers
→ Intégration des contraintes d’UX/UI
→ Satisfaction du client (correspondance avec son besoin)
→ Respect de l’identité graphique de la marque / produit / charte graphique.
→ Ils sont aussi chargées de concevoir l’interface du produit / projet. (Ce que l’utilisateur final utilisera constamment)
Développeurs
→ Choix d’un framework performant et efficace qui correspond au besoin et aux compétences de celui-ci mais également du projet sur lequel il va travailler.
→ Une bonne maintenabilité du projet avec une conception qui permet la compréhension du code projet pour l’arrivée d’un nouveau développeur dans l’équipe est essentiel.
→ Rédiger du code fonctionnel et maintenable.
→ Optimisation du code pour augmenter les performances et réduire les coûts.
Une phrase très cliché mais qui est souvent représentatif pour les personnes qui ne sont pas du métier.
Si c’est pas beau c’est la faute du designer, si ça marche pas c’est celle du développeur.
C’est dire l’impact et le rôle de ces deux métiers dans le processus de création d’une solution.
Comment respecter les ambitions et les contraintes des intervenants ?
Le respect des ambitions et des contraintes des intervenants doit se faire dès lors des réunions de lancement du projet. En écoutant et en comprenant les capacités de chaque intervenant. Il permet également un développement plus prospère du projet. Avec un accord de confiance envers chaque intervenant on multiplie inconsciemment son investissement.
Il faut rester cohérent et respecter ses collaborateurs en travaillant avec des technologies qu’ils maitrisent ou avec lesquels ils ont l’habitude de travailler ou dans le cas contraire prévoir un temps de formation et d’apprentissage.
Les ambitions de certains intervenants peuvent parfois dépasser les ressources définies ou allouées au projet. C’est dans ces moments qu’il faut savoir réguler les ambitions tout en respectant les choix de ces intervenants. Il faut savoir comprendre et identifier ces raisons pour comprendre le fond du problème.
Quelles bonnes pratiques peut-on en tirer ?
Voici les bonnes pratiques que l’on peut tirer pour architecturer une application en respectant les ambitions et contraintes des différents intervenants d’un projet. Les différents intervenants cité plus haut ont chacun leur rôle à chaque étape du processus.
- Définir les objectifs du projet. Il est important de bien comprendre les raisons pour lesquelles l’application est développée, quels sont les besoins des utilisateurs et quels sont les résultats attendus.
- Identifier les intervenants du projet. Il est important de connaître les différents acteurs du projet, leur rôle et leur contribution. Cela inclut les développeurs, les chefs de projet, les designers, les utilisateurs finaux et le client.
- Respecter les intervenants et leurs ambitions. Dans un projet il est important de respecter les ambitions des différents intervenants il est bénéfique pour l’équipe que les intervenants possèdent et mettent en avant leurs ambitions. Cela permet d’apporter une certaine motivation ainsi qu’une inertie dans le projet.
- Comprendre les contraintes du projet. Il est important de connaître les limites du projet, telles que le budget, les délais, les ressources humaines et techniques disponibles, les normes et réglementations à respecter.
- Établir un plan de développement et une étude de faisabilité. Une fois que les objectifs, les intervenants et les contraintes du projet sont connus, il est possible de définir un plan de développement. Celui-ci doit inclure les fonctionnalités de l’application, les technologies à utiliser, les étapes de développement et les délais associés. Il est également recommandé de réaliser une étude de faisabilité pour s’assurer que le projet est réalisable.
- Tester et valider l’application. Il est important de tester l’application afin de s’assurer qu’elle fonctionne correctement et de corriger les éventuels bugs. Une fois l’application validée, elle peut être mise en production.
Nous venons de voir comment structurer une application en tenant compte des ambitions et limites de chacun. Mais ce n’est que le début. Nous aborderons dans un prochain article les méthodes que nous avons mit en place et pour mieux comprendre, concevoir et réaliser votre projet.
Retrouvez tous les articles en design, tech & stratégie sur notre chouette blog 🔥
