Il y a quelques semaines, nous posions la question à notre communauté LinkedIn : sur un projet mobile, qu’est-ce qui est le plus difficile à arbitrer ? 100% des répondants ont répondu : le périmètre fonctionnel face au budget. Un résultat net, qui nous a donné envie d’aller plus loin.
Pourquoi ces arbitrages sont-ils si difficiles ?
Un projet mobile n’est pas un projet comme les autres. Les cycles sont courts, les attentes utilisateurs élevées, les contraintes techniques spécifiques… et les décisions à prendre, nombreuses.
Ce qui rend ces arbitrages particulièrement délicats, ce n’est pas leur complexité technique. C’est leur dimension humaine et organisationnelle. Ils impliquent des parties prenantes aux intérêts parfois divergents, des contraintes budgétaires réelles, et des pressions temporelles qui poussent à trancher vite. Parfois, trop vite.
Voici les cinq tensions les plus structurantes, et quelques repères pour les aborder avec méthode.
1. Périmètre fonctionnel vs budget : l’arbitrage le plus politique
Sans surprise, c’est celui que les décideurs citent en premier dans notre sondage. Et pour cause : contrairement aux autres, il n’a pas de solution purement technique.
La tension périmètre / budget surgit rarement au moment où on l’attend. Elle s’installe progressivement, au fil des sprints, quand des fonctionnalités « indispensables » apparaissent en cours de route, quand un arbitrage technique impacte le planning, quand le backlog grossit plus vite que le budget ne le permet.
Ce qui aide concrètement :
Définir un MVP rigoureux dès le cadrage : pas un MVP « marketing » qui intègre tout, mais un périmètre minimal réellement testé et assumé par toutes les parties prenantes. Poser des critères d’arbitrage partagés avant que les tensions n’apparaissent : qu’est-ce qui est non négociable ? Qu’est-ce qui peut attendre la V2 ? Qui a le dernier mot ?
Un bon cadrage initial ne supprime pas cet arbitrage. Il donne les outils pour le gérer sans que chaque décision devienne un rapport de force.
2. UX vs contraintes techniques : quand l’idéal se heurte au réel
L’équipe design imagine un parcours fluide, élégant, centré utilisateur. L’équipe technique identifie des contraintes d’architecture, de performance, de compatibilité qui compliquent l’implémentation.
Cette tension est saine ; elle est même le signe que les deux expertises sont présentes et impliquées. Elle devient problématique quand elle n’est pas arbitrée de façon structurée.
Ce qui aide concrètement :
Faire travailler UX et technique ensemble dès la phase de conception, pas en séquence. Un designer qui comprend les contraintes techniques produit des solutions plus robustes. Un développeur qui comprend les intentions UX implémente avec plus de fidélité. La co-conception réduit les aller-retours et les compromis de dernière minute.
Et quand un arbitrage est inévitable, documenter la décision et sa justification, pour éviter de la remettre en question à chaque sprint.
3. Rapidité de livraison vs qualité du code : le piège de la pression calendaire
« On a besoin de la fonctionnalité pour la démo de la semaine prochaine. »
Cette phrase, tout chef de projet l’a entendue. Et parfois, on livre. En acceptant des compromis techniques qui semblent mineurs sur le moment.
Le problème : ces compromis s’accumulent. La dette technique grandit silencieusement. Et un jour, ce qui aurait pris deux jours à développer en prend dix, parce que la base de code n’est plus maîtrisée.
Ce qui aide concrètement :
Traiter la dette technique comme un sujet de pilotage à part entière, pas comme un problème à résoudre « plus tard ». Réserver une part systématique de chaque sprint à la remédiation technique. Et surtout, rendre cette dette visible auprès des décideurs : pas pour les alarmer, mais pour qu’ils comprennent les conséquences réelles des arbitrages calendaires.
4. Alignement métier / IT : la source de friction la plus sous-estimée
Les équipes métier ont une vision du produit. Les équipes IT ont une vision de l’architecture. Ces deux visions ne se parlent pas toujours naturellement. Et quand elles ne sont pas alignées, le projet avance en zigzag.
Les symptômes sont connus : des spécifications qui changent après que le développement a commencé, des fonctionnalités livrées qui ne correspondent pas aux usages réels, des recettes qui révèlent des malentendus qui auraient pu être évités bien plus tôt.
Ce qui aide concrètement :
Investir dans des ateliers de co-construction en début de projet : pas pour produire des documents, mais pour créer une compréhension partagée du problème à résoudre. Impliquer les utilisateurs finaux le plus tôt possible dans le processus. Et nommer clairement un Product Owner avec une vraie disponibilité et un vrai pouvoir de décision.
5. Dette technique vs nouvelles fonctionnalités : l’arbitrage oublié
C’est peut-être le plus insidieux des cinq. Parce qu’il est rarement posé explicitement.
Dans la plupart des organisations, la pression porte sur les nouvelles fonctionnalités : ce que le produit va faire de plus. La dette technique, elle, est invisible pour les non-techniciens. Elle ne figure pas dans les roadmaps. Elle n’est pas dans les présentations au COMEX.
Et pourtant, elle conditionne directement la capacité du projet à évoluer, à intégrer de nouvelles technologies (comme l’IA générative) et à maintenir une vélocité de développement satisfaisante dans la durée.
Ce qui aide concrètement :
Rendre la dette technique visible et quantifiée : en temps de développement, en risques, en coût de maintenance. Intégrer sa résorption dans la roadmap produit, au même titre que les évolutions fonctionnelles. Et sensibiliser les décideurs à ce sujet dès le cadrage, avant que la situation ne devienne critique.
Ce que ces cinq arbitrages ont en commun
Ils partagent tous la même caractéristique : ils sont beaucoup plus simples à gérer quand ils sont anticipés que quand ils surgissent en cours de projet.
La plupart des difficultés que rencontrent les équipes en cours de delivery trouvent leur origine dans un cadrage insuffisant : des décisions non prises, des responsabilités floues, des critères d’arbitrage non définis.
Ce n’est pas une question de méthode agile ou non. C’est une question de préparation.
Un bon cadrage de projet mobile ne cherche pas à tout prévoir : c’est impossible. Il cherche à poser les bonnes fondations pour que les décisions imprévues puissent être prises avec méthode, transparence et alignement entre toutes les parties prenantes.
Vous pilotez un projet mobile et vous reconnaissez certaines de ces tensions ? Nos experts sont disponibles pour un premier échange : l’occasion d’identifier ensemble les points de vigilance avant qu’ils ne deviennent des obstacles. On en parle ? 💬
Vous souhaitez réagir ou en savoir plus ?
On vous offre un café et, en bonus, la check-list de votre cahier des charges, pour ne rien oublier.
Vous êtes partant(e) ?