Question 1

Comment écrire des critères d'acceptation pour une fonctionnalité qui n'est pas déterministe ?

Accepted Answer

En remplaçant « le système affiche X » par des propriétés vérifiables et un taux attendu, mesurés sur un échantillon de cas réels. Un critère d'acceptation classique suppose une sortie unique et reproductible ; une fonctionnalité IA n'en a pas. La recette se fait alors sur un jeu de cas construit avec le métier, et l'essentiel du travail de spécification porte sur ce qui doit arriver quand le système se trompe.

Question 2

Comment budgéter une fonctionnalité qui utilise un modèle de langage ?

Accepted Answer

En séparant le coût de construction, qui ressemble à n'importe quel développement, et le coût d'usage, qui n'existe pas ailleurs : chaque utilisation se paie. Une fonctionnalité classique amortie devient gratuite ; une fonctionnalité IA coûte d'autant plus qu'elle réussit. Le budget doit donc comporter une ligne récurrente, un plafond, et une décision écrite sur ce qui se passe quand ce plafond est atteint.

Question 3

Comment construire une application mobile sur une API existante qu'on ne peut pas modifier ?

Accepted Answer

En traduisant les réponses de l'API en entités propres à l'application dès la frontière, plutôt qu'en laissant sa structure remonter dans les écrans. Le découpage domaine / données / présentation coûte quelques fichiers de plus et rend l'application insensible aux changements de format côté serveur. Sans cette traduction, une évolution de l'API devient une reprise de tous les écrans qui l'utilisaient.

Question 4

Comment démarrer une plateforme de mise en relation quand ni l'offre ni la demande n'est encore là ?

Accepted Answer

En renonçant à lancer les deux côtés en même temps. On choisit la face la plus difficile à recruter — presque toujours celle qui doit publier — et on lui rend un service qui a de la valeur même si l'autre côté est vide. La plateforme n'est utile aux deux qu'ensuite, et ce décalage doit être assumé dans le produit comme dans le budget.

Question 5

Qu'est-ce qu'une équipe de développement doit comprendre du tiers payant avant de coder ?

Accepted Answer

Qu'un dossier n'est pas une transaction unique mais une chaîne à deux payeurs — l'assurance maladie et la complémentaire — chacun avec ses règles, ses délais et ses motifs de rejet. L'essentiel de la complexité n'est pas dans le cas nominal mais dans le rejet : il arrive des semaines plus tard, il faut savoir à quel dossier le rattacher, et le corriger sans perdre l'historique.

Question 6

Qu'apporte le paiement en ligne à une association, au-delà du confort ?

Accepted Answer

Il supprime le travail de relance et de rapprochement, qui coûte bien plus de temps aux bénévoles que l'encaissement lui-même. Le gain n'est pas dans l'acte de payer mais dans ce qui l'entoure : plus de chèques à déposer, plus de tableau de suivi, un état des impayés à jour en permanence. En contrepartie, il faut traiter des cas que le chèque masquait — paiement en plusieurs fois, aides, remboursements.

Question 7

Pourquoi la gestion des créneaux d'un club sportif est-elle si difficile à informatiser ?

Accepted Answer

Parce qu'un planning de club n'est pas un agenda mais une allocation sous contraintes : des créneaux, des installations, des encadrants et des groupes, dont la disponibilité change en permanence. L'erreur habituelle est de partir d'un calendrier ; il faut partir des contraintes, et concevoir l'outil autour de l'exception plutôt qu'autour du cas nominal.

Question 8

Faut-il développer une application mobile native, ou un site web suffit-il ?

Accepted Answer

Cela dépend de ce qui existe déjà. Si vous avez une application web moderne, emballez-la : Capacitor la met dans une coque native en réutilisant l'essentiel du code, et réécrire l'interface en React Native ou Flutter ne rapporterait rien sur un outil de gestion. Si l'existant est un site serveur classique, il n'y a rien à emballer et le natif multiplateforme est justifié. La technologie se choisit après avoir regardé l'existant, pas avant.

Question 9

Comment construire une feuille de route produit réaliste et utile ?

Accepted Answer

En la structurant par horizons plutôt que par dates. Le trimestre en cours est engageant et détaillé ; le suivant est une intention par thème ; au-delà, ce sont des problèmes à résoudre, sans solution ni date. Une feuille de route qui promet des fonctionnalités datées à douze mois est fausse le jour où elle est publiée, et son principal effet est de détruire la confiance quand la réalité s'en écarte. Ce qui doit rester stable, ce sont les objectifs ; ce qui doit bouger, ce sont les moyens de les atteindre.

Question 10

Comment utiliser les notifications push sans faire fuir les utilisateurs d'une application mobile ?

Accepted Answer

En n'envoyant que ce qui concerne personnellement l'utilisateur et appelle une action de sa part. Trois règles gouvernent le reste : ne demander l'autorisation qu'après avoir montré à quoi elle sert, laisser un réglage fin par type de notification plutôt qu'un interrupteur unique, et respecter le fuseau horaire ainsi que les heures de repos. Une autorisation refusée est très difficile à récupérer — la demander au premier lancement est l'erreur la plus coûteuse et la plus fréquente.

Question 11

Comment réussir l'adoption d'une nouvelle application par les équipes qui l'utiliseront ?

Accepted Answer

En traitant l'adoption comme une partie du projet, pas comme une formation de fin de parcours. Ce qui fonctionne : associer quelques utilisateurs dès le cadrage, livrer d'abord à un petit groupe volontaire, accepter de modifier l'outil après les premiers retours, et fixer une date de bascule ferme. Une application refusée l'est presque toujours parce qu'elle demande plus d'efforts qu'elle n'en fait gagner à celui qui la saisit — et ce déséquilibre se corrige dans la conception, pas dans la conduite du changement.

Question 12

Comment rédiger une user story ou une spécification claire pour une équipe de développement ?

Accepted Answer

En décrivant le problème et les critères d'acceptation observables, jamais la solution technique. Une demande exploitable tient en une page : qui, quel problème, ce qui doit être vrai à la fin, les cas particuliers connus, et ce qui est explicitement hors périmètre. La section « hors périmètre » est celle qui évite le plus de malentendus, et c'est celle qu'on oublie systématiquement.

Question 13

Comment prioriser un backlog quand toutes les demandes sont présentées comme urgentes ?

Accepted Answer

En remplaçant la question « est-ce urgent ? » par « que se passe-t-il si on ne le fait pas ce trimestre ? ». Cette reformulation fait apparaître le coût réel de l'attente, qui est souvent nul. Ensuite, imposez une contrainte de rareté : une liste ordonnée sans ex æquo, et une capacité affichée. Tant que plusieurs demandes peuvent être « prioritaires » simultanément, aucune priorisation n'a lieu.

Question 14

Peut-on réutiliser un même logiciel pour plusieurs métiers différents ?

Accepted Answer

Oui, à condition de séparer dès le départ le socle technique du vocabulaire métier. Nous exploitons une même plateforme de gestion d'association sous quatre marques — Vibe-it pour les écoles de danse, Moove-IT pour les clubs sportifs, et deux autres verticales — avec un socle commun et des parcours propres à chaque univers. Ouvrir un nouveau marché coûte alors une fraction du coût initial.

Question 15

Qu'est-ce qu'un MVP et comment définir son périmètre ?

Accepted Answer

Un MVP est la plus petite version qui résout un problème réel de bout en bout pour un utilisateur, et dont on peut tirer un apprentissage. Ce n'est pas une version incomplète, ni une maquette, ni un prototype jetable : ce qu'il fait, il le fait correctement, en production. Le bon critère de découpage n'est pas « quelles fonctionnalités enlever » mais « quel utilisateur, sur quel cas, peut aller au bout sans nous ».

Question 16

Comment décider de supprimer ou d'arrêter une fonctionnalité d'une application ?

Accepted Answer

En regardant trois chiffres : le nombre d'utilisateurs distincts sur les trois derniers mois, la part qu'elle représente dans les demandes de support, et le coût qu'elle impose aux évolutions voisines. Une fonctionnalité utilisée par moins de 2 % des utilisateurs et qui complique chaque livraison doit être retirée. Le vrai obstacle n'est jamais technique : c'est qu'aucune organisation ne récompense la suppression.

Question 17

Comment se déroule un atelier de cadrage de projet applicatif ?

Accepted Answer

Sur deux à quatre semaines, en quatre ateliers de deux à trois heures : cartographier le processus actuel tel qu'il se passe réellement, identifier les irritants et les chiffrer, arbitrer le périmètre de la première version, puis valider les critères de succès et les risques. Les participants doivent inclure ceux qui font le travail, pas seulement ceux qui le dirigent — c'est la condition qui détermine la qualité du résultat.

produit

Spécifier une fonctionnalité IA : les critères d'acceptation ne marchent plus

Le coût d'une fonctionnalité IA ne se calcule pas comme les autres

Une application mobile posée sur une API qu'on ne maîtrise pas

Une marketplace a deux faces : par laquelle commencer

Le tiers payant expliqué à une équipe technique

Encaisser pour une association : ce que le paiement en ligne change vraiment

Le planning d'un club : le problème le plus sous-estimé

Emballer ou réécrire : comment nous choisissons une techno mobile

Écrire une feuille de route qui survit à trois mois

Notifications push : ce qui marche, et ce qui fait désinstaller

Faire adopter un outil qui remplace des habitudes

Écrire une demande qui ne se transforme pas en malentendu

Prioriser quand tout est urgent

Un même logiciel, quatre marchés : comment nous déclinons une plateforme par verticale

MVP : ce que ça veut dire, et surtout ce que ça ne veut pas dire

Comment on décide d'arrêter une fonctionnalité

Nos ateliers de cadrage : le déroulé, heure par heure

Un projet à cadrer ?