Pourquoi 70% des projets mobiles ratent-ils leur échéance ?
Le scénario, on le voit chaque semaine à Montréal comme à Toronto. Un fondateur esquisse sa vision sur un tableau blanc (ou dans Figma, pour les plus organisés), une designer crée des maquettes pixel-parfaites, et l'équipe d'ingénierie s'installe pour builder. Deux jours plus tard, les questions pleuvent sur Slack: l'app doit-elle fonctionner offline? Comment le backend gère les requêtes concurrentes? REST ou GraphQL? Redux ou Zustand? Personne dans le channel n'a les réponses.
Le temps que ces questions se règlent (souvent dans des threads Slack de 40 messages), on a déjà perdu deux, trois semaines. Les devs font des suppositions contradictoires. Quelqu'un rebuild une feature parce que la spec a changé en mid-sprint. Les maquettes Figma? On les traite comme des specs fonctionnelles, sauf qu'elles n'en sont pas. Résultat: les budgets triplent et les dates de livraison glissent au point où le board commence à poser des questions.
Ce n'est pas un problème de devs lents ou de mauvaise gestion de projet, et c'est important de le dire. C'est le fossé entre la vision et la spécification. Le fondateur a un modèle mental clair de son produit, sauf que ce modèle existe uniquement dans sa tête. La designer le traduit en layouts visuels. Les développeurs interprètent ces layouts et devinent la logique métier. C'est un jeu de téléphone, sauf que chaque joueur est convaincu d'avoir la bonne version.
Ce chiffre-là dit quelque chose que la plupart des équipes n'osent pas formuler à voix haute: le vrai problème, ce n'est pas la vitesse d'exécution. C'est la clarté de la spec. J'ai vu des équipes de trois développeurs livrer plus vite qu'une équipe de douze, simplement parce que les trois savaient exactement quoi builder. Une équipe lente avec des requis clairs bat une équipe rapide avec des specs floues. À tout coup.
Comment les startups spécifient-elles actuellement les applications mobiles ?
Approche 1 : maquettes sans spécifications techniques
C'est le modèle dominant, surtout dans les startups early-stage. La designer remet des maquettes haute fidélité dans Figma: chaque écran, bouton, interaction. L'équipe assume que les maquettes « sont » les specs, et le dev démarre. Quelques heures plus tard, le lead dev réalise que les maquettes ne répondent à aucune des vraies questions. Comment l'auth fonctionne? Quel est le contrat API? Que se passe-t-il quand le réseau tombe? L'app cache-t-elle les données en offline?
Alors le dev invente des réponses (ce qui crée du rework quand le fondateur voit le résultat et dit « non, c'est pas ça que je voulais »), ou il envoie un message Slack au fondateur pour chaque décision. Le progrès ralentit à la vitesse des réponses Slack. Les meetings se multiplient. Les change requests affluent parce que le fondateur découvre seulement maintenant ce que son app va réellement faire.
Approche 2 : spécification menée par le développeur
Le fondateur remet les maquettes et dit « go, buildez ». Le lead dev devient l'architecte par défaut. REST ou GraphQL, Redux ou Zustand, natif ou React Native, SQLite ou Realm: chaque décision technique lui revient. Ces choix sont souvent corrects techniquement, mais est-ce qu'ils correspondent à la vision du fondateur ou au business model? Pas nécessairement. Un dev pourrait choisir un backend monolithique quand le fondateur prévoyait des microservices, ou passer trois semaines à optimiser le sync offline alors que le MVP assume une connexion constante.
On se retrouve avec une app techniquement solide qui résout le mauvais problème. Ou pire (et on voit ça souvent), une app qui fonctionne mais dont l'architecture rend la prochaine feature excessivement chère à builder. Le scope creep devient inévitable parce que l'architecture n'a jamais été conçue pour accueillir la vraie roadmap du produit.
Approche 3 : listes de fonctionnalités dans les feuilles de calcul
Certaines équipes essaient d'être systématiques. Elles créent une feature list dans un Google Sheet: login, profil utilisateur, recherche, notifications, paiement. Chaque ligne a sa description, son dev assigné et son deadline. Le problème? Une feature list, ce n'est pas une spec. « Paiement » pourrait signifier 100 choses différentes. Quels providers? Quelles devises? Comment on gère les remboursements? Que se passe-t-il si le paiement échoue à mi-transaction parce que l'utilisateur est dans le métro?
On découvre les lacunes quand le dev commence à coder, et à ce stade les requis sont déjà codifiés. Modifier quoi que ce soit exige du rework. La feature list devient une to-do list, pas un plan. Le progrès semble bon en surface (« 12 features sur 20 complétées! »), mais le produit réel s'éloigne de la vision à chaque item complété.
Comment la spécification guidée par l'IA change-t-elle le développement mobile ?
Specira transforme le handoff entre la maquette et le code. Au lieu de remettre des Figma aux devs en espérant qu'ils devinent correctement (on sait tous comment ça finit), le fondateur passe par des sessions structurées guidées par l'IA. Le résultat: des requis complets, spécifiques à la plateforme, prêts avant que le premier commit ne soit pushé.
Le processus commence exactement où les maquettes s'arrêtent. Le fondateur ou le PM passe en revue ses maquettes avec Specira, et l'IA pose des questions de clarification ancrées dans la réalité du dev mobile. Comment l'app se comporte offline? Combien de temps on cache les données? Qu'est-ce qui trigger un sync? Ce ne sont pas des questions génériques tirées d'un template. Elles sont spécifiques aux features dans les maquettes et aux choix techniques qui font la différence entre un dev mobile simple et un cauchemar.
Ce qu'on obtient, ce n'est pas un autre document Google Docs que personne ne lira. C'est une spec opérationnelle: interaction maps montrant les state changes pour chaque action utilisateur, requis spécifiques à iOS et Android, contrats API complets avec définitions d'endpoints et schémas de réponse. Si l'app doit fonctionner sans connectivité (genre dans le métro de Montréal), les offline patterns sont documentés. Pareil pour le error handling et les targets de performance.
Les devs s'installent avec cette spec et voient exactement ce qu'ils doivent builder. Pas de devinettes. Pas d'interprétation. Pas de meeting d'une heure pour clarifier ce que le flux de paiement doit faire quand l'utilisateur perd sa connexion en pleine transaction. La réponse est déjà dans la spec, et c'est une décision du fondateur, pas une supposition du développeur.
L'impact est immédiat et on le sent dès le premier sprint. Le dev démarre avec une clarté totale sur ce qu'il faut builder. L'équipe produit sort du chemin critique parce que la spec contient déjà toutes leurs décisions. Les ingénieurs codent à pleine vitesse au lieu de switcher constamment entre le code et la clarification de requis. Et les code reviews? Elles se concentrent sur la qualité de l'implémentation, pas sur des débats « est-ce que la feature devrait marcher comme ci ou comme ça ».
Les scope changes en mid-sprint chutent drastiquement parce que le scope était verrouillé avant le premier commit. Le feature creep devient visible immédiatement: la spec est la source de vérité. Quand une nouvelle demande ne correspond pas au document, c'est clairement un changement de scope, pas un malentendu. On peut évaluer son impact réel sur le timeline au lieu de le découvrir à mi-chemin du sprint.
Quels résultats les startups mobiles peuvent-elles espérer ?
Les équipes qui adoptent cette approche voient des changements mesurables dans leur façon de travailler, et ça se voit dès la première semaine. Le handoff du produit à l'ingénierie n'implique plus de devinettes ou de semaines de réunions de clarification. Les requis sont documentés, spécifiques, prêts à coder. Point.
Le scope creep diminue parce que la spec, c'est le contrat. Chaque nouvelle demande est évaluée par rapport au document, pas ajoutée ad hoc pendant un standup. Les équipes qui voyaient habituellement 5 à 7 changements par sprint tombent à 2 ou 3, et ces changements sont des petits ajustements, pas des reworks de features qui font exploser les délais et le budget.
Autre avantage concret (et celui-là, les CTOs l'adorent): les devs backend et frontend travaillent en parallèle à partir du même contrat API. L'équipe backend sait exactement ce que l'app mobile attend. L'équipe frontend sait exactement ce que le backend va fournir. Zéro meeting de coordination nécessaire. Le contrat est la source de vérité.
La qualité du code s'améliore aussi, et c'est pas anodin. Les développeurs se concentrent sur une implémentation propre plutôt que de deviner les requis. Le rework diminue. La dette technique recule parce que l'architecture a été conçue par rapport à une spec complète, pas découverte au fil du développement en mode « on verra bien ».
L'évolution de la transmission de conception chez Figma : Quand Figma a introduit son système de conception en 2018, l'équipe a basculé de maquettes vagues à des spécifications d'interaction complètes. On ne documentait plus seulement la mise en page visuelle, mais chaque changement d'état, condition d'erreur et délai d'animation. Résultat : la vélocité de développement a augmenté de 50 % au premier trimestre. Pourquoi ? Parce que les ingénieurs passaient zéro temps à deviner ce qui avait été conçu. Ils implémentaient exactement ce qui était spécifié, sans va-et-vient. Ce même principe s'applique aux applications mobiles : les specs structurées avant le code éliminent la « taxe de transmission de conception » qui tue la plupart des projets.
Point clé à retenir
Le fossé entre la vision produit et l'implémentation n'est pas un problème de coordination. C'est un problème de spécification. Les maquettes sont des mises en page, pas des specs. Une spec exige des détails spécifiques à la plateforme, des contrats API complets, un comportement hors ligne, une gestion d'erreurs et des motifs de gestion d'état. Les équipes qui spécifient complètement avant le codage livrent 40 % plus vite, avec 70 % moins de changements de portée en cours de sprint. L'investissement est remboursé en jours, pas en semaines.
Questions fréquemment posées
Les requis d'une application mobile doivent être spécifiques et actionnables. On commence par les parcours utilisateur montrant comment les utilisateurs se déplacent dans l'application, puis on documente chaque écran avec ses changements d'état, entrées et sorties. On spécifie les différences de plateforme explicitement : iOS et Android ont des motifs UI différents, des conventions de navigation et des modèles d'permissions. Un requis comme « l'utilisateur peut rechercher des éléments » est trop vague. Un requis approprié se lit comme : « l'utilisateur appuie sur l'icône de recherche sur l'écran d'accueil. La barre de recherche devient active avec le clavier visible. Les résultats se chargent à partir du point de terminaison API /v1/search?q=QUERY avec un délai de rebond défini à 300ms. Si aucun résultat n'existe, afficher l'état vide avec des requêtes suggérées. Appuyer sur un résultat navigue vers l'écran de détail. Le bouton arrière ou le geste de balayage ferme la recherche et revient à l'écran d'accueil. »
Ce niveau de détail empêche les va-et-vient entre la conception et le développement. Les développeurs peuvent implémenter exactement ce qui était spécifié. Les testeurs peuvent vérifier que c'est conforme à la spécification. Les designers peuvent confirmer que le comportement s'aligne avec leur vision.
Une spécification complète d'application mobile comprend sept composantes. Premièrement, les requis fonctionnels : ce que fait chaque écran, ce qui se passe sur chaque action utilisateur, quels appels API sont effectués et quelles données s'affichent. Deuxièmement, l'architecture technique : natif ou multiplateforme, motifs backend, approche de gestion d'état et conception de base de données. Troisièmement, les contrats API : chaque endpoint que le backend doit fournir, schémas de requête et réponse, codes de statut, messages d'erreur et flux d'authentification. Quatrièmement, le comportement hors ligne : si l'application fonctionne hors ligne, ce qui se synchronise, ce qui ne se synchronise pas, comment les conflits se résolvent et quel retour l'utilisateur voit. Cinquièmement, les directives de plateforme : conformité aux directives d'interface humaine iOS, conformité au Material Design, motifs de navigation spécifiques à la plateforme et gestion des permissions. Sixièmement, les cibles de performance : à quelle vitesse les écrans doivent se charger, taux de trames d'animation, seuils d'expiration de réseau et objectifs d'impact batterie. Septièmement, la sécurité et la gestion des données : quelles données sont chiffrées, ce qui est mis en cache localement, comment les données sensibles sont protégées et comment l'utilisateur peut supprimer son compte.
Sans ces sept composantes, les développeurs font des suppositions. Avec elles, le développement est une simple exécution.
On ne tente pas de communiquer une idée d'application par des conversations ou des courriels. On la documente. On commence par les parcours utilisateur montrant comment les utilisateurs accomplissent les tâches clés. Pour chaque parcours, on documente les écrans impliqués, les données affichées, les actions disponibles et les changements d'état. On crée des spécifications d'interaction mappant chaque geste et appui à un changement d'état résultant ou un appel API. On rédige les contrats API : chaque URL d'endpoint, méthode HTTP, paramètres obligatoires, schéma de réponse et conditions d'erreur. Si l'application a un comportement hors ligne complexe, on documente la stratégie de synchronisation. Si elle utilise les notifications push, on spécifie les types de notification et quand elles s'envoient. Si elle gère les téléchargements de fichiers, on spécifie les limites de taille et les formats supportés.
Puis on programme une présentation avec l'équipe. Ils lisent la documentation d'abord, puis on la révise ensemble. En 90 minutes, on peut couvrir la spécification entière de l'application. Les développeurs posent des questions de clarification, mais ces questions concernent les cas limites, pas les fonctionnalités fondamentales ou le comportement. Le résultat est une compréhension partagée. Tout le monde construit la même application.
