1Adaptation 1 : Interface adaptée au dispositif (ordinateur ou mobile)

Cette adaptation est à l’exécution, car elle est initiée et gérée automatiquement par le système. En fonction du type
d’interface détecté (ordinateur ou mobile), le système ajuste dynamiquement l’affichage et les fonctionnalités. Justification :
Le système détecte le dispositif utilisé (écran large ou mobile) et adapte en temps réel l’interface pour offrir une expérience
optimale, sans intervention directe de l’utilisateur.
Dispositif : L’adaptation se base sur les caractéristiques du dispositif (taille de l’écran, type d’entrée) pour proposer une
présentation et une navigation adaptées.
Utilisateur : Indirectement, l’utilisateur bénéficie de cette adaptation en recevant une interface optimisée pour son appareil,
facilitant l’expérience globale.
Justification : Le système gère automatiquement les ajustements selon le dispositif, ce qui permet une ergonomie adaptée
aux besoins de l'utilisateur en fonction de son appareil.

Adaptation 2 : Mode voiture pour une interface simplifiée Cette adaptation est à la conception, car elle est initiée
manuellement par l’utilisateur en cliquant sur le bouton pour activer le mode voiture. L’interface a été préconçue pour
répondre à ce besoin spé[Link] : L’utilisateur déclenche volontairement le mode voiture, ce qui en fait une
interaction planifiée et prévue en amont lors de la conception de l’application.
Environnement : Le contexte de conduite impose une simplification de l’interface (moins d’éléments visuels) pour
minimiser la distraction et garantir la sécurité. Utilisateur : L’utilisateur choisit d’activer le mode voiture en fonction de son
besoin immédiat, comme conduire tout en passant une commande.
Justification : Cette adaptation repose sur une interaction intentionnelle de l’utilisateur pour répondre aux contraintes de son
environnement (sécurité au volant).

2abstarct de Cameleon .
IHM abstraite (Abstract UI) Nom : IHM abstraite.
Justification : Ce niveau représente une interface utilisateur décrite de manière indépendante des détails spécifiques de la
plateforme ou des technologies utilisées. Elle se concentre sur les structures générales et les interactions logiques, par
exemple, définir qu'un formulaire doit contenir un champ de saisie et un bouton, sans préciser leur apparence ou leur
comportement exact. Ce niveau facilite la transition entre les concepts et une implémentation plus concrète tout en
maintenant une certaine flexibilité d'adaptation.

IHM concrète (Concrete UI) Nom : IHM concrète.

Justification : Ce niveau décrit une interface utilisateur en tenant compte des spécificités de la plateforme ou de la
technologie cible, comme les widgets ou composants de l'interface. Par exemple, le champ de saisie devient un TextField
dans une bibliothèque spécifique, et le bouton prend une forme précise (taille, couleur). Ce niveau est plus détaillé que l'IHM
abstraite et permet de s'approcher de la phase finale d'implémentation tout en adaptant les éléments aux contraintes
matérielles et logicielles.

Tâches et Concepts (Tasks & Concepts) Nom : Tâches et Concepts.

Justification : Ce niveau représente la description des tâches que l'utilisateur doit accomplir et les concepts qui sous-tendent
ces tâches. Il est indépendant de toute considération d'interface ou de plateforme. Par exemple, dans une application de
gestion, une tâche pourrait être "Ajouter un utilisateur" avec des concepts comme "Utilisateur" ou "Profil". Ce niveau est
essentiel pour structurer l'interaction en se basant sur les besoins métiers et les objectifs de l'utilisateur.

IHM finale (Final UI) Nom : IHM finale.

Justification : Ce niveau correspond à l'implémentation complète de l'interface utilisateur, telle qu'elle est perçue par
l'utilisateur final. Elle prend en compte les spécificités techniques, les contraintes de la plateforme (comme le système
d'exploitation ou le type d'appareil) et les exigences ergonomiques. Par exemple, une application pour mobile inclura des
optimisations pour l'écran tactile et une navigation adaptée, avec un rendu visuel et fonctionnel prêt à être utilisé.

L'Ingénierie Dirigée par les Modèles (IDM) repose sur l'utilisation de modèles comme artefacts centraux dans le processus
de développement logiciel. Dans le cadre de CAMELEON, l'IDM est mise en œuvre pour gérer les transformations entre
différents niveaux d'abstraction (ex : tâches et concepts, IHM abstraite, IHM concrète, IHM finale), permettant ainsi une
spécification unique qui peut être adaptée à plusieurs plateformes ou contextes d'utilisation grâce à des mécanismes comme
la réification et la traduction.

3 IconButton et ProductCard. IconButton : Ce composant a été conçu pour être réutilisé de manière flexible dans plusieurs
parties de l’application. Son rôle principal est d’afficher des icônes cliquables, ce qui en fait un élément clé pour diverses
interactions utilisateur, comme ajouter un plat au panier, fermer un panier, ou afficher un menu déroulant. ProductCard : Ce
composant a été conçu pour afficher les informations d’un produit de manière uniforme et structurée, avec des options
d’interaction (ajouter au panier, afficher les détails du produit, etc.). Il est essentiel pour maintenir une présentation cohérente
des produits sur la plateforme.

IconButton : Il est réutilisé dans plusieurs parties de l’interface, pour des actions variées, comme l'ajout de plat, la
suppression d'un item du panier (croix), l'ouverture du panier, et même dans des menus déroulants. Son design uniforme
permet de l’utiliser dans des contextes différents sans compromettre la cohérence visuelle.
ProductCard : Ce composant a été réutilisé dans l’interface tactile pour la fonctionnalité de drag and drop (glisser-déposer)
dans le panier. De plus, il est utilisé dans des modales de partage ou d’envoi de produits, où la card est présentée pour une
interaction rapide.

4 Nous avons appliqué un Design System explicite. Un Design System explicite est un ensemble de règles, composants, et
styles centralisés et documentés, permettant d'assurer une cohérence visuelle et fonctionnelle sur tous les produits. Il repose
sur des outils dédiés pour gérer les éléments de conception et facilite la collaboration entre designers et dé[Link]
avons utilisé Figma comme outil pour centraliser et documenter les éléments graphiques de notre Design System (typo,
couleurs, composants comme boutons ou formulaires). Pour la partie développement, nous avons intégré Material-UI (MUI),
qui fournit une bibliothèque de composants réutilisables, alignée sur notre Design System. Cela garantit que les éléments
graphiques définis dans Figma sont directement traduits en composants fonctionnels dans l'application.
De plus, nous appliquons la méthodologie Atomic Design, qui permet de structurer notre Design System en éléments de base
(atomes), composants plus complexes (molécules, organismes), et interfaces complètes. Cette approche garantit une grande
modularité et une évolution cohérente de notre système tout au long du développement.

Nous avons mis en place un Design System explicite avec Figma et Material-UI pour une conception cohérente et une mise
en œuvre efficace. En utilisant la méthodologie Atomic Design, nous avons assuré que chaque élément soit réutilisable et
modulable.

5 Nous avons choisi la mise en place d’un Backend for Frontend (BFF). Pour cela, nous avons conçu un BFF spécifique
pour chaque type de frontend (ex : application mobile, web), afin qu'il serve de couche intermédiaire entre le frontend et les
services backend. Ce BFF est responsable d’adapter les payloads et de centraliser les appels aux services backend, simplifiant
ainsi la logique côté [Link] choix du BFF s’explique par les avantages qu’il apporte :Adaptation des payloads : Les
données renvoyées par les services backend sont adaptées selon les besoins spécifiques de chaque frontend, ce qui évite de
gérer des logiques complexes directement dans le frontend. Amélioration des performances : Le BFF centralise les appels
backend, ce qui permet de réduire le nombre de requêtes effectuées par le frontend. Flexibilité : Il permet une évolution
indépendante du backend et du frontend, offrant une meilleure modularité. Moins de Requêtes depuis le front

Micro-frontends : Indépendance des Composants : Les micro-frontends permettent de découper le frontend en petites parties
indépendantes, chacune gérant son propre backend. Cela se rapproche de la gestion des microservices dans le backend. Pas de
Workflow dans le Frontend : Chaque micro-frontend est responsable de ses propres données et logiques, ce qui élimine la
gestion d'un workflow global complexe dans le [Link] de Technologies : Différents micro-frontends peuvent utiliser
des technologies et des frameworks différents selon leurs besoins spécifiques, offrant une grande flexibilité.

Inconvénients : Complexité de Mise en Place : Implémenter des micro-frontends nécessite une architecture complexe avec
des solutions de "container" frontend, ce qui peut être lourd à gérer. Difficultés de Test et de Déploiement : La mise en place
des tests (notamment end-to-end) et la gestion des déploiements peuvent être compliquées, notamment si plusieurs micro-
frontends dépendent d'un backend commun. Avantages : Cette solution évite des modifications importantes dans
l’architecture technique et peut simplifier le projet.
Inconvénients : Adapter les besoins métier pour contourner les limites techniques n’est pas toujours pertinent. Cela peut
mener à des compromis qui dégradent l’expérience utilisateur ou la qualité du produit.
En comparaison, le BFF apporte un compromis équilibré entre flexibilité et évolutivité, en isolant les responsabilités et en
évitant un couplage trop fort entre backend et frontend.

Architecture Traditionnelle (Frontend avec appels directs au Backend) Avantages : Simplicité : L'architecture classique est
simple et directe, avec le frontend qui appelle directement les services backend. Cela ne nécessite pas de couche
intermédiaire (comme le BFF), ce qui simplifie la mise en œuvre. Contrôle Total : Le frontend a un contrôle total sur ses
appels backend, ce qui peut être avantageux dans des scénarios où la logique côté frontend est plus complexe et nécessite une
gestion [Link]énients :Complexité dans le Frontend : Lorsque des appels backend complexes doivent être adaptés ou
transformés pour chaque type de frontend (web, mobile), cela peut entraîner une logique complexe et difficile à maintenir
directement dans le [Link] des Requêtes : Si plusieurs services backend sont nécessaires, cela peut entraîner
une multiplication des requêtes, ce qui peut nuire aux performances, surtout côté mobile ou avec des connexions lentes.