Application mobile à Dunkerque, et ce qui fait vraiment déraper un projet

Nous publions nos propres applications sur Google Play. Nous connaissons la revue, ses refus, les versions cibles imposées chaque année et les pages obligatoires, parce que nous les subissons sur nos applications, pas parce qu'on nous l'a raconté.

Industrie, logistique portuaire, commerces, associations et collectivités du Dunkerquois.

Un projet en retard attend rarement du code

C'est le constat le plus constant que nous ayons, et il surprend toujours : quand un projet d'application prend trois mois de retard, le développement n'est presque jamais en cause. Le chantier attend un texte, un accès ou un arbitrage.

La raison est mécanique. Le développement est planifiable et se rattrape ; une décision qui n'est pas prise ne se rattrape pas, elle attend. Et pendant qu'elle attend, l'équipe est arrêtée sur ce point précis, quelle que soit sa vitesse.

Ce qu'il faut préparer de votre côté

Les textes, et surtout les courts. Les longues descriptions s'écrivent facilement. Ce qui bloque, ce sont les libellés de boutons, les messages d'erreur, les confirmations. Il en faut des dizaines, personne ne les a prévus, et une application sans eux ne peut pas être finie.

Les comptes, avec la personne qui peut y accéder. Compte développeur, hébergement, nom de domaine, service d'envoi. Le problème n'est pas de les créer, c'est de retrouver qui détient l'accès quand la personne concernée a changé de poste. Ce point se règle en une heure au début et coûte une semaine au milieu.

Les données réelles. Un catalogue, une liste d'adhérents, un fichier de tarifs. Travailler sur des données inventées donne une application qui marche en démonstration et qui casse le premier jour, parce que la réalité contient des cas que personne n'imagine.

Une personne qui décide. Pas un comité : quelqu'un qui peut trancher entre deux options en vingt-quatre heures. C'est l'élément le plus déterminant de la liste, et celui qui figure le moins souvent dans un cahier des charges.

Deux téléphones de test, dont un vieux. Le vôtre est probablement récent. Vos utilisateurs, non. Un appareil de quatre ans révèle en cinq minutes ce qu'aucune simulation ne montre.

Quand chaque élément bloque réellement

Tout n'est pas nécessaire au premier jour, et savoir quand chaque chose devient bloquante évite de tout demander d'un coup :

• Avant de commencer : la personne qui décide, et les données réelles, même partielles.
• Pendant le développement : les textes courts, au fil des écrans.
• Avant la publication : les comptes et leurs accès, la politique de confidentialité, les captures pour le magasin.
• Avant la mise en service : les téléphones de test, entre les mains de vraies personnes.

Ce que nous faisons pour que cette liste ne reste pas lettre morte

Nous la remettons au début, datée, avec pour chaque élément la date à laquelle son absence arrêtera le chantier. Ce n'est pas une formalité administrative : c'est ce qui permet de dire « nous sommes bloqués depuis mardi sur ce point » plutôt que de constater le retard un mois plus tard. Un projet où le client sait exactement ce qu'on attend de lui avance deux fois plus vite qu'un projet où il le découvre au fur et à mesure.