← Travaux03 / Voyage en Banque
Produit en développementRéservation de vols intégrée au compteProduct design · Prototypage IA · Service design2026

Voyage en Banque

Concevoir, arbitrer et tester rapidement un module de réservation de vols intégré à la banque — directement depuis un téléphone.

Le défi n'était pas seulement de dessiner un parcours. Il fallait réduire le temps entre une idée, un prototype testable et une décision.

Accueil du module voyage dans l'application bancaire : destinations, voyageurs enregistrés et réservations.
Accueil voyageOuvrable sur le téléphone d'un décideur, sans installation.

Résumé en 30 secondes

Enjeu
Intégrer rapidement une expérience de réservation de vols dans l'application bancaire.
Contrainte
Faire avancer le produit tout en intervenant sur plusieurs sujets et auprès de plusieurs squads en parallèle.
Réponse
Construire avec Lovable une boucle courte entre conception, prototype mobile, test et arbitrage.
Ma part
Architecture d'expérience, décisions produit, prototype fonctionnel et première expérimentation de contribution gouvernée.
01 / 04

Le vrai problème était le délai de décision

Plusieurs squads avançaient à des rythmes différents. Le prototype devait rester ouvrable et modifiable à tout moment, pour arbitrer sans attendre.

J'ai donc conçu une boucle où chaque hypothèse importante devient une interface fonctionnelle, testée par les décideurs sur leur propre téléphone, puis corrigée dans la même journée.

  1. 01IntentionUne décision produit écrite, un périmètre, une règle.
  2. 02Prototype fonctionnelL'intention devient une interface navigable, pas une maquette.
  3. 03Test mobileUn lien ouvert sur le téléphone du décideur, dans son contexte réel.
  4. 04ArbitrageLe désaccord se tranche sur un écran manipulable, pas sur une capture.
  5. 05ItérationCorrection faite juste après la revue, y compris depuis mon téléphone.
02 / 04

Un atelier produit accessible depuis le téléphone

Avec Lovable, mes intentions produit devenaient des interfaces navigables. Les décideurs testaient le parcours sur leur propre téléphone.

L'écran d'intention de vol ne demandait que quatre informations essentielles au client — les familles tarifaires, les bagages et la flexibilité arrivent ensuite, comme conséquences de l'option choisie.

  • Type de trajetAller-retour ou aller simple, avant toute saisie.
  • TrajetDépart et arrivée dans un seul bloc, inversion en un geste.
  • DatesUne seule ligne, dépendante du type de trajet.
  • Voyageurs & cabineRegroupés : une décision, pas deux écrans.
  • RechercheAction unique, atteignable au pouce.

Lovable a accéléré l'exécution. Les décisions, contraintes et arbitrages produit restaient sous ma responsabilité.

03 / 04

La vitesse ne devait pas réduire la qualité de la décision

Recherche et réservation de vols depuis l'application bancaire : paiement en dirhams, contraintes tarifaires explicites et dotation prise en charge dans le parcours.

Le module réutilise la charte et les composants existants. La valeur venait de l'architecture de l'expérience et de la vitesse de test.

Direction visuelle

Système bancaire existant, volontairement conservé pour accélérer l'intégration et l'adoption.

Écran budget et dotation touristique, avec le taux du dirham du jour.
Budget & dotationCe qu'il reste de la dotation, et le taux verrouillé avant l'engagement.
Écran des réservations enregistrées : vols et hôtels sous une référence unique.
RéservationsVol, hôtel et paiement sous une seule référence : un changement a un seul endroit où s'appliquer.
04 / 04

De l'itération mobile à la contribution gouvernée

Testé ensuite avec le Marketing : ajuster certains contenus depuis son téléphone, dans un périmètre limité, sans attendre un cycle de production.

Premier principe : chaque expertise contribue dans son propre langage, mais seulement dans son périmètre — l'IA tenant le garde-fou.

Ouvrir la contribution ne signifie pas abandonner le contrôle.

Réalisé et testé
  • Modification de textes par le Marketing
  • Contribution depuis un téléphone
  • Périmètre limité aux contenus autorisés
  • Mise à jour plus rapide du prototype
Envisagé · non développé
  • Contribution du Produit, du Marketing et d'autres expertises
  • Règles différentes selon le rôle
  • Analyse de cohérence par l'IA
  • Validation humaine pour les changements engageants
  • Traçabilité et possibilité de retour arrière

Ajouter un module avec l'IA

Il fallait ajouter un module voyage à une application bancaire existante. La difficulté tenait en une phrase : créer quelque chose de nouveau sans que cela paraisse étranger au reste de l'application.

  1. 01
    Générer la première versionClaude Code produit une première version de l'expérience, ce qui permet d'explorer le parcours et de tester des idées plus vite.
  2. 02
    Confronter au design systemLe fichier Figma existant sert de référence : composants, espacements, typographie, couleurs, motifs d'interaction. La comparaison rend visible ce qui est cohérent et ce qui doit changer.
  3. 03
    Réutiliser, ajuster ou créerChaque écart reçoit une décision simple : réutiliser un composant existant, ajuster le nouvel écran pour suivre le système, ou créer un motif seulement quand c'est nécessaire.
  4. 04
    Remonter dans FigmaUne fois l'expérience stable, le design est transféré dans Figma : les détails y sont affinés et les éléments restants remplacés par les composants officiels.
Le déroulé

Besoin→Génération avec Claude Code→Comparaison au design system→Réutiliser / Ajuster / Créer→Affinage dans Figma→Design final

Ce que j'en retiens : l'IA fait aller plus vite, mais l'essentiel n'était pas de générer l'interface. C'était de garantir que le module reste perçu comme une partie du même produit. L'IA accélère la production, le design system tient la cohérence.

Emplacement — comparaison module / design systemcapture à fournir
Emplacement — reconstruction dans Figmacapture à fournir

Registre des arbitrages

Ce que chaque décision a coûté, ou évité

  1. 01

    Une intention plutôt que seize filtres

    Coût assumé

    Le réglage fin est perdu : trois options supposent un tri assumé par le produit.

  2. 02

    Règles tarifaires traduites en conséquences

    Coût assumé

    Chaque règle doit être traduite à la main avant d'être affichée.

  3. 03

    L'IA explique, la source bancaire fixe le prix

    Risque évité

    Des conditions générées à la volée devant un écran de paiement.

Ma contribution

J'ai inscrit le module dans l'identité visuelle existante et concentré mon intervention sur l'expérience, les règles métier et la vitesse d'intégration.

Architecture d'expérience
Réservation de vol complexe ramenée à un parcours bancaire compréhensible.
Décisions produit
Hiérarchie des contraintes tarifaires, de la cabine, des voyageurs et du paiement.
Système de prototypage
Boucle courte entre intention, prototype mobile, test et arbitrage.
Gouvernance émergente
Périmètre de contribution ouvert à une autre expertise, sans dépassement.
Chaîne de livraisonCadrage → passation
  1. CadrageRéaliséUn seul objectif retenu : la recherche et la réservation de vols intégrées au compte.
  2. Architecture d'expérienceRéaliséSeize paramètres de comparateur ramenés à quatre entrées essentielles, organisées autour de l'intention de voyage.
  3. Contribution encadréeTestéPérimètre ouvert au Marketing sur les textes seuls, avec relecture avant publication.
  4. PassationRéaliséLe produit fonctionnel sert de spécification : états, règles et bifurcations lisibles.
Produit fonctionnel

C'est le même lien que celui envoyé aux décideurs : ouvrable sur téléphone, il tient à la fois de la preuve et de la spécification.

Ouvrir le produit fonctionnel ↗
Projet suivant04 / Crédit & Engagements

Réunir le crédit et ses garanties dans un seul poste de travail, où chaque dossier porte son état.

Ouvert aux postes senior product / UX-UI designer en télétravail

hello@badrbenali.com LinkedIn
← Tous les travauxBadr Benali — Product design