HeadersBlog.jpg
logo Axopen

18+

années
d'expérience

60+

experts
techniques

150K

écoutes de notre podcast

Comment intégrer l'UX/UI dans ses applications métier sans ralentir les projets ?

Dès qu'on intègre un UX dans un projet de développement d’application métier, on ne va pas se mentir : quand on est technique ou CTO, on a souvent l’impression que tout ralentit. Il faut prendre le temps de réfléchir, de tester, de se poser des questions sur l’interface… et forcément, on peut avoir le sentiment qu’on n’avance plus aussi vite qu’avant !

Est-ce qu’on a vraiment raison de penser que l’UX/UI fait perdre du temps ? Au contraire, comment peut-il nous en faire gagner sur le long terme ? Et surtout, comment intégrer concrètement l’UX/UI dans le développement de nos applications métiers sans ralentir les projets ?

IMG_6230.png
Andréa Gil laranjo, La créativelogo Linkedin
Chargée de communication & UX/UI designerMis à jour le 28 Oct 2026

Pourquoi on a la sensation que les UX/UI ralentissent les projets d'applications ?

Demandez à des développeurs ce qu’ils pensent de l’arrivée d’un UXL'UX signifie "user experience" et définit l'ensemble des éléments permettant l'utilisation du site web de façon optimale./UIL'UI signifie "user interface", et se compose de tous les éléments graphique d'une interface utilisateur. designer sur un projet d’application métier, la réponse est souvent la même : « Ça va nous ralentir. » Et en vrai, ils n’ont pas complètement tort. L’UX pose des questions, beaucoup de questions.

Pourquoi ce bouton est ici ? C’est vraiment nécessaire ? Est-ce que l’utilisateur va bien comprendre cette information ? Est-ce que cet écran répond à un vrai besoin ou il est juste la pour remplir?

Le problème, ce n’est pas de se poser ces questions, mais de trouver le temps d’y répondre quand le projet est déjà lancé, que les développements avancent et que les deadlines approchent.

Deux mondes se rencontrent, avec des façons de travailler et des rythmes différents. Sur la planète des développeurs, une fois qu’on a compris le besoin, on avance, on code et on voit rapidement le résultat. La route est plutôt tracée, les étapes sont définies, on sait où on va et comment y aller. Mais quand un UX/UI débarque dans l’équation, il faut parfois ralentir, remettre certains choix en question et attendre que la réflexion avance avant de pouvoir continuer.

Parce que sur la planète créativité, les idées ont besoin de temps pour émerger. Il faut explorer différentes pistes, chercher des références, tester des approches et parfois revenir en arrière pour trouver la bonne solution. La réflexion ne suit pas toujours une ligne droite, et c’est justement ce qui fait sa richesse.

Forcément, quand ces deux planètes se rencontrent, ça peut créer des frictions. Pour les développeurs, attendre qu’une décision soit prise ou devoir reprendre quelque chose déjà développé, c’est du temps en plus. Pourtant, ce n’est pas forcément du temps perdu : c’est surtout un décalage entre deux façons de réfléchir et d’avancer.

C’est justement ce qu’on a exploré dans notre podcast sur l’importance de l’UX/UI designer, en confrontant les points de vue de nos équipes UX et Tech. Parce qu’entre ceux qui veulent avancer rapidement et ceux qui ont besoin de prendre du recul pour trouver la bonne solution, il y a parfois un monde, voire une galaxie !

Et puis il faut le dire, les réflexions UX ne s’arrêtent pas aux écrans : les réflexions touchent aussi au business et au marketing, ce qui peut élargir les discussions et multiplier les allers-retours entre ces différents pôles par extension. D’où l’importance de faire travailler tout ce petit monde ensemble dès le début du projet :)

Pourquoi l'UX/UI, ça reste essentiel dans les projets d’applications métiers ?

Il faut quand même le rappeler: l’UX/UI c’est essentiel pour les applications métiers, et s’en passer, ça peut avoir un coût assez élevé à terme !

  • La dette UX peut coûter cher. On connaît tous déjà la dette technique (qu’on essaie de gérer malgré les évolutions et les innovations) ; mais on peut aussi parler de dette UX ! Au début, l’application est simple : un tableau, quelques boutons, deux ou trois écrans. Puis on ajoute une fonctionnalité par-ci, une pop-up par-là, une nouvelle colonne, un bouton supplémentaire, puis un autre. Et on finit avec un tableau à 52 colonnes et une dizaine de boutons entassés en haut de l'écran ! Chaque ajout semblait raisonnable et nécessaire sur le moment, mais au final on finit avec une interface difficile à maintenir, à garder cohérente et à faire évoluer sans tout casser.
  • L'adoption utilisateur est essentielle, et l’UX y est pour beaucoup ! Une application peut être techniquement excellente, mais si les utilisateurs n’arrivent pas à s’en servir, à trouver leurs fonctionnalités, et finalement à l’adopter, c’est la cata… Et puis il faut bien l’avouer, les attentes des utilisateurs en matière d’UX n'arrêtent pas de monter : à force d'utiliser des applications grand public bien pensées au quotidien, les utilisateurs deviennent naturellement plus exigeants quand ils retrouvent leur outil de travail. Une application interne n’a pas besoin d’être spectaculaire ou encore bling-bling, elle doit être compréhensible et efficace pour celles et ceux qui l’utilisent plusieurs heures par jour.
  • Le temps qu'on gagne après les premiers développement grâce à l’UX, peut largement compenser celui qu'on a « perdu » au début. Comme tout, il faut juger les investissements sur le long terme ! Un bon travail UX, au-delà d’un on-boarding plus rapide et d’une prise en main plus facile, c’est aussi à terme moins de tickets support et au final une équipe plus efficace. C'est pour ça qu'il vaut mieux l'intégrer le plus tôt possible, idéalement avant même la toute première ligne de code.

Et puis avec l’IA, ça change aussi un peu la donne : on peut maintenant prototyper beaucoup plus vite certaines idées, parfois en quelques heures, sans forcément mobiliser un développeur dès le départ ! Après ça soulève aussi quelques questions : est-ce que l’IA va finir par remplacer les designer ? Est-ce que les développeurs auront encore besoin de designers demain ?

Bref, je divague, mais tout ça pour vous dire que c’est plutôt rentable au final cette affaire d’UX ! Mais du coup, comment faire concrètement pour intégrer l’UX/UI au début d’un projet de développement d’application métier ?

Comment intégrer l'UX/UI dès le début du projet de développement d’application métier ?

  1. Comprendre le métier et le contexte : avant d’écrire la première ligne de code, il faut savoir à qui on s’adresse. Quel est leur métier ? Dans quel environnement travaillent-ils ? Avec quels outils ? (Eh oui, on pourrait presque aller jusqu’à compter leurs cafés… presque.) Entretiens, observation sur le terrain : l’objectif est de concevoir un outil qui colle vraiment à leur quotidien.
  2. Identifier les irritants et les besoins : qu’est-ce qui leur fait perdre du temps aujourd’hui ? Qu’est-ce qui manque, qu’est-ce qui agace ? En échangeant avec eux, on repère ce qui pourrait réellement leur faciliter la vie.
  3. Co-construire avec toute l’équipe : l’UX n’est pas l’affaire des seuls designers. Développeurs, chefs de projet, métier : chacun apporte son regard. Les ateliers servent à confronter les idées et à s’accorder sur les priorités. Mieux vaut les organiser tôt, car il est toujours plus simple de s’aligner au début que de tout revoir en plein développement.
  4. Concevoir, tester et ajuster avant de développer : vient ensuite le temps des parcours utilisateurs et des premières maquettes. Mais une idée évidente pour nous ne l’est pas forcément pour tout le monde ! Faire tester rapidement un prototype permet de voir ce qui fonctionne et ce qui coince, et d’éviter de développer quelque chose qui ne servira pas.
  5. Mesurer et améliorer en continu : une fois l’application en production, le travail continue. Analytics, retours utilisateurs, tickets de support, observations terrain : tout cela montre comment l’outil est réellement utilisé. On peut alors identifier ce qui doit évoluer et améliorer l’expérience au fil du temps.

Comment et quand intégrer l'UX/UI dans la TMA ?

Le travail UX ne s’arrête pas une fois l’application mise en production. Elle entre alors en phase de Tierce Maintenance Applicative (TMA), et c’est souvent là que l’UX passe un peu à la trappe. Pourtant, c’est justement à ce moment-là qu’on commence à avoir des retours concrets sur la façon dont l’application est utilisée au quotidien.

Mais alors, comment continuer à améliorer l’expérience utilisateur sans tout remettre à plat à chaque évolution ?

  • Regarder les tickets de support : si les utilisateurs remontent régulièrement le même problème, ce n’est peut-être pas juste un bug. Il y a peut-être quelque chose à revoir dans l’interface ou dans le parcours.
  • Profiter des évolutions pour améliorer l’existant : quand une fonctionnalité doit être modifiée, autant en profiter pour se demander si elle est toujours adaptée aux besoins des utilisateurs et si on peut leur simplifier la vie.
  • Prendre régulièrement le temps d’en discuter : pas besoin d’organiser de grands ateliers à chaque fois. Quelques minutes pendant une réunion de suivi peuvent suffire pour faire remonter les problèmes et décider lesquelles traiter en priorité.
  • Repérer les petites galères du quotidien : si les utilisateurs doivent multiplier les clics, contourner certaines fonctionnalités ou demander régulièrement de l’aide, c’est peut-être qu’il y a un vrai problème d’ergonomie derrière.

L’idée, ce n’est pas de tout refaire à chaque fois, mais d’intégrer l’UX au fil des évolutions, en s’attaquant d’abord aux problèmes qui gênent le plus. De petites améliorations régulières peuvent faire une vraie différence, sans avoir besoin de lancer un gros chantier.

Jusqu’où aller dans l’UX pour rester efficace sur les applications métier ?

Contrairement à une application grand public, une application métier est généralement imposée par l’entreprise et fait partie du quotidien. L’objectif n’est donc pas de faire du beau, mais du pratique. L’utilisateur veut trouver une information et réaliser sa tâche efficacement, sans prise de tête.

Il faut donc se concentrer sur l’essentiel : hiérarchiser les données, faciliter l’accès aux fonctionnalités et soigner les écrans les plus utilisés. Pas besoin de tout révolutionner : des repères stables et une navigation familière sont souvent bien plus utiles qu’une interface originale qui oblige à tout réapprendre.

Et même si tout le monde a son avis sur une maquette, les choix UX doivent avant tout répondre aux besoins des utilisateurs et aux contraintes du métier, pas aux préférences personnelles de chacun.

Qui décide de l'UX dans les projets ?

Spoiler : il n'y a pas vraiment de réponse universelle comme 42 :) Sur le papier, on pourrait penser que c’est à l’UX de décider. Après tout, c’est son métier, donc c’est lui qui est le mieux placé pour trancher, non ? On peut aussi se dire que ce sont les utilisateurs qui devraient décider, puisque ce sont eux qui vont utiliser le logiciel toute la journée.

Bon, dans la réalité, c’est le chef de projet côté client, celui qui finance le projet, qui a le dernier mot. Vous allez me dire : “ Oui, c’est lui qui commande l’application, donc c’est normal. “ Sûrement, mais ce qu’on voit souvent dans les projets, c’est que certaines décisions sont malheureusement motivées par des questions de goût personnel !

Et c’est assez dingue (et un peu frustrant) quand on y pense : tout le monde a un avis sur le visuel, alors que personne ne va vraiment se permettre de critiquer le code de l’application. Un client ne va jamais ouvrir un fichier et dire : « C’est moche, votre fonction, elle est mal nommée, cette balise-là ? Hmm, moi, je n’aurais pas fait ça. »

C'est humain de donner son avis sur ce qu’on voit, mais ce n’est pas forcément une bonne manière de prendre une décision.

Alors, comment éviter que ça se transforme en bataille d’opinions ?

  • Première chose : la démarche UX doit être comprise par l’ensemble de l’équipe dès le début. Si les développeurs et les porteurs de projet ne comprennent pas pourquoi telle décision a été prise, ils vont naturellement la remettre en question à chaque réunion.
  • Deuxième chose : mesurer autant que possible l’impact des décisions. On peut surveiller le support technique avant et après une évolution, observer les analytics et identifier les étapes où les utilisateurs abandonnent ou rencontrent des difficultés. Les chiffres ne vont évidemment pas décider à notre place, mais ils permettent de sortir du simple ressenti. Et ça évite parfois quelques longues discussions sur la couleur d’un CTA.

Conclusion : l’UX/UI pour les applications métiers, un peu de temps investi pour en gagner beaucoup ensuite !

Alors, est-ce que l’intégration d’un UX/UI ralentit un projet d’application métier ? Oui, probablement un peu, mais ce n’est pas un problème (sauf si l’UX n’est pas très bon bien sûr :)) .

Il faut surtout voir ce que ce temps permet ensuite d’éviter ! Intégrer l’UX dès le début permet de mieux comprendre les utilisateurs, de poser les bonnes questions avant de développer et de garder une cohérence au fil des évolutions. Il faut aussi que toute l’équipe partage cette démarche et qu’à un moment, on soit capable de trancher.

Et puis, une fois qu’on a trouvé une interface qui fonctionne, il faut arrêter de vouloir tout changer tous les quatre matins. Une application agréable à utiliser au quotidien, c’est aussi une application dans laquelle on garde ses repères. Pour quelqu’un qui passe plusieurs heures par jour sur le même outil, devoir retrouver ses marques après chaque mise à jour, c’est frustrant. Mieux vaut faire des choix clairs, travailler sur les vrais problèmes et éviter de courir après chaque nouvelle tendance.

Au fond, c’est assez simple : il faut écouter les besoins des utilisateurs, c’est le cœur du job :)