Un backlog qui s'allonge plus vite qu'il ne se vide, des fonctionnalités ajoutées parce qu'un client les a demandées, une roadmap qui décrit des livraisons plutôt que des décisions. Ou l'inverse : un produit qui marche techniquement et que les utilisateurs n'adoptent pas. Dans les deux cas, ce qui manque n'est pas du développement, c'est un cadre pour arbitrer.
Ils nous font confiance
Votre roadmap liste des fonctionnalités, jamais les problèmes qu’elles règlent.
Impossible dans ce cas de dire, six mois après, si la livraison a servi à quelque chose.
Chaque demande client entre directement dans le backlog.
Le produit finit par ressembler à la somme de ses dix clients les plus bavards.
Deux personnes de votre équipe décrivent le produit différemment.
Si vous ne savez pas le dire en interne, vos utilisateurs ne le comprendront pas non plus.
Vous connaissez votre taux d’inscription, pas votre taux d’usage réel.
Un compte créé n'est pas un usage, et c'est souvent là que se cache la mauvaise nouvelle.
La fonctionnalité dont vous êtes le plus fiers est celle que personne n’utilise.
Elle est peut-être bonne, mais elle n'est pas trouvable, ou pas au bon moment du parcours.
Vos arbitrages se règlent en réunion, à l'intuition, sans donnée d'usage.
C'est alors la personne la plus convaincante qui décide, pas celle qui a raison.
Chaque étape se termine par un livrable utilisable et par une porte de sortie : vous pouvez vous arrêter là, ce qui a été produit continue de servir. Vous engagez donc une étape à la fois, et vous ajustez le périmètre à chaque jalon plutôt qu'au moment où il est trop tard pour le faire.
01 Cadrage
1 à 2 semaines
Nous repartons des utilisateurs et du problème qu'ils cherchent à régler, pas de la liste de fonctionnalités en attente. La plupart des backlogs bloqués le sont parce qu'ils mélangent trois problèmes différents que personne n'a séparés.
Livrable la problématique posée, les utilisateurs cibles et les critères de décision.
02 Diagnostic
1 à 2 semaines
Nous croisons les données d'usage existantes avec des entretiens et des tests sur le produit actuel. L'écart entre ce que les équipes croient et ce que les utilisateurs font est presque toujours la matière la plus utile du projet.
Livrable le diagnostic d'usage, les points de rupture du parcours et les irritants classés.
03 Conception
1 à 2 semaines
Nous arbitrons ce qui entre dans la prochaine version et ce qui n'y entre pas, puis nous le maquettons et nous le testons. Un prototype mis entre les mains de cinq utilisateurs tranche en deux jours ce qu'une réunion ne tranche pas en trois semaines.
Livrable un prototype testé, le périmètre arbitré et ce qui a été écarté, avec le motif.
04 Structuration
1 semaine
La roadmap se construit sur des problèmes à régler et des résultats attendus, avec les critères qui permettront de dire si c'était la bonne décision. Elle devient alors un outil d'arbitrage, et plus une liste de promesses.
Livrable la roadmap priorisée, les indicateurs de succès et le rythme de revue.
05 Construction
2 à 3 semaines par incrément
Chaque incrément est livré en état de servir et mis devant des utilisateurs. Le design system, quand il en faut un, se construit au fil des écrans réels plutôt qu'en amont, où il produit des composants dont personne n'a besoin.
Livrable la version en service, sa documentation et le retour des premiers usages.
06 Pilotage
à 3 et 6 mois
Nous comparons l'usage réel aux indicateurs posés à la structuration, et nous acceptons le verdict, y compris quand il dit qu'une fonctionnalité attendue ne sert pas. Cette mesure est ce qui empêche la roadmap de redevenir une liste de souhaits.
Livrable le bilan d'usage chiffré et la roadmap révisée.
Décrivez votre contexte, vos outils et votre échéance : vous repartez avec un périmètre de départ et un ordre de grandeur budgétaire. Ce que vous saisissez nous sert de base au premier échange, vous n'aurez pas à le redire.
Un produit se structure mal quand la décision n'appartient à personne. Nous ne réglons pas les cas où trois directions veulent trois produits différents sans arbitre désigné, et un cadrage ne remplacera jamais cette décision. Il échoue aussi quand on veut structurer sans jamais parler aux utilisateurs, ou quand la roadmap est déjà engagée auprès d'un client et qu'aucun arbitrage n'est réellement possible. Nous partons donc des usages constatés plutôt que des demandes, nous écrivons ce que nous renonçons à faire autant que ce que nous faisons, et quand le vrai sujet est une décision interne à prendre, nous vous le disons avant de proposer un dispositif.
Structurer un produit demande moins d'outils que de décisions, mais le produit finit toujours par se raccorder à ce que vous avez déjà : votre CRM, vos contenus, vos canaux de vente et vos briques d'IA. Ces raccordements se décident au cadrage, parce qu'ils pèsent plus lourd sur le calendrier que les écrans eux-mêmes.
Votre projet ne mobilise pas les mêmes compétences selon l'endroit où il bloque : de la recherche utilisateur quand le besoin est encore flou, un design system quand l'outil devra grandir, un renfort produit quand ce qui manque est la décision plus que les mains. Le pilotage reste le même d'un bout à l'autre de la mission, l'équipe autour se compose sur votre sujet.
Depuis 15 ans
Quinze ans à concevoir, développer et mettre en service des produits numériques : product managers, designers et développeurs qui ont vu passer les cycles et savent ce qui tient en production. Nous partons du problème métier plutôt que de la technologie, et nous allons jusqu'à la mise en service au lieu de nous arrêter à la recommandation.
70+ projets livrés
Le pilotage du projet reste chez nous, du premier atelier à la mise en service : c'est ce qui permet de décider vite quand une hypothèse tombe en cours de route. Autour de ce noyau, nous mobilisons les expertises que votre sujet demande vraiment, et non l'inverse, où le profil disponible finit par dicter la solution.
Sans licence ni redevance
Dès le paiement, sans licence ni redevance : le code, les maquettes et la documentation vous sont livrés, et une autre équipe peut les reprendre. Nous ne vendons pas d'accès à une plateforme qui resterait la nôtre.
Savoir dire non
Quand un logiciel du marché couvre l'essentiel du besoin, quand un process change encore tous les mois, quand la donnée n'est pas prête : nous le disons au cadrage, avant le devis. Un projet mal parti coûte plus cher à tout le monde qu'un projet refusé.
Financement public
Pégase Digital est affilié au Crédit d'Impôt Innovation. Une entreprise soumise à l'impôt en France peut, sous conditions, prétendre à un crédit d'impôt équivalant à 20 % des dépenses externalisées de conception et de développement, quand la solution est nouvelle et innovante sur son marché de référence. L'éligibilité s'apprécie projet par projet, avec votre conseil fiscal.
Votre entreprise a moins de deux ans ? Le remboursement immédiat peut être demandé plutôt qu'imputé sur l'impôt des exercices suivants.
Un enjeu en amène souvent un autre.
Saisies manuelles, exports récurrents, relances à heure fixe : chaque tâche répétée est du temps que vos équipes ne passent pas ailleurs.
Vous savez que l'intelligence artificielle peut servir, sans savoir où la brancher ni comment la cadrer pour qu'elle tienne en conditions réelles.
Vos process tiennent sur des fichiers partagés, des mails et des habitudes que personne n'a jamais écrites.
Vous collectez des données depuis des années sans qu'aucune décision ne s'appuie vraiment dessus.
Vous voulez savoir si l'idée tient devant de vrais utilisateurs avant d'engager un budget de développement.
Votre trafic monte, vos demandes entrantes non, et personne ne sait dire quel canal a amené le dernier client signé.
Vos clients passent du site à l'application puis en boutique, et doivent tout réexpliquer à chaque fois.
Par le tri, pas par le développement. Nous regroupons les demandes en problèmes utilisateurs, et la plupart des backlogs se réduisent d'eux-mêmes : dix demandes différentes décrivent souvent la même friction. Ce qui reste se priorise sur la fréquence du problème et sur son effet mesurable, pas sur l'insistance de celui qui l'a demandé.
Le corriger, dans la majorité des cas. Une refonte complète coûte plusieurs mois pendant lesquels rien ne s'améliore pour vos utilisateurs, et elle reconduit souvent les mêmes erreurs. La refonte se justifie quand le socle technique empêche toute évolution, et ce diagnostic se pose avant de choisir, pas après.
De deux à quatre semaines selon la taille du produit et le nombre de personnes à embarquer. L'atelier de cadrage se chiffre séparément du reste et se termine par des décisions écrites, pas par une intention. Si votre besoin est surtout de trancher vite entre deux directions, un sprint de deux semaines suffit souvent.
Rarement au démarrage. Un design system, c'est une bibliothèque de composants d'interface partagée entre les équipes. Il devient rentable quand plusieurs personnes conçoivent en parallèle sur plusieurs écrans. Construit trop tôt, il produit des composants dont personne ne se sert, et il ralentit les premières versions au lieu de les accélérer.
En la testant avant de la construire. Un prototype cliquable mis devant cinq utilisateurs représentatifs donne une réponse en quelques jours, pour une fraction du coût du développement. Si le test ne peut pas se faire, la question devient : combien coûterait l'erreur, et peut-on se la permettre.
Oui, et c'est le cas le plus fréquent. Nous intervenons soit pour un cadrage ponctuel, soit en renfort dans votre équipe sur la durée, avec vos rituels et vos outils. Notre travail consiste alors autant à transmettre la méthode qu'à produire, pour que vos arbitrages suivants se prennent sans nous.
