Commencer par une tâche complète
« Nous avons besoin d’un CRM » ne définit pas encore un livrable. Décrivez plutôt une action : un commercial crée une demande, un responsable la valide et le client reçoit un statut. Précisez qui intervient, quelles informations sont nécessaires et ce qui prouve que le parcours fonctionne.
Ce découpage aide à distinguer le premier besoin des améliorations futures. Il permet aussi de comparer des devis qui portent sur le même travail, au lieu d’opposer uniquement leurs montants.
Écrire les limites avant de construire
Le périmètre doit préciser les utilisateurs, les écrans, les règles de gestion et les connexions incluses. Une migration de dix fichiers propres ne représente pas le même travail qu’un historique incomplet à reconstituer. La qualité des données et la disponibilité des accès sont donc des éléments du cadrage.
- Un parcours prioritaire et un responsable de validation.
- Des exemples de données et les rôles autorisés à les consulter.
- Les intégrations et prérequis fournis par chaque partie.
- Les exclusions et la manière de chiffrer une demande supplémentaire.
Séparer prix de construction et coût d’usage
Demandez quels frais restent après la livraison : hébergement, messagerie, API, abonnements, sauvegardes et interventions. Identifiez qui détient les comptes et qui surveille le fonctionnement. Un prix initial comparable peut couvrir des responsabilités très différentes.
Le Service Manual de GOV.UK recommande d’examiner le coût total de possession et la capacité à changer de solution. Ces critères techniques sont utiles pour comparer des options ; ils ne constituent pas une estimation de votre projet.
Prévoir une validation observable
Remplacez « le résultat doit nous plaire » par quelques scénarios vérifiables : une demande complète est enregistrée, une personne non autorisée ne peut pas la lire, une erreur est visible et les données peuvent être exportées. Testez ces scénarios avec les personnes qui utiliseront le système.
Distinguez une anomalie par rapport au périmètre approuvé d’une nouvelle idée. Les conditions de correction, d’acceptation et d’évolution doivent apparaître dans le devis. La propriété du code ne remplace pas la remise des accès et des instructions nécessaires à son utilisation.
Ce que propose le premier sprint Okys
Okys affiche un premier sprint à 5 000 €, sur 14 jours, pour un workflow prioritaire ou un MVP ciblé dont le périmètre est approuvé avant construction. Vous payez la moitié au lancement, le solde à la livraison du périmètre convenu. Le code vous appartient.
Ce format ne promet pas un ERP complet ou toutes les fonctions d’un SaaS dans un seul sprint. Les accès, les contraintes et le livrable sont examinés avant confirmation. À la livraison, vous pouvez décider de vous arrêter ou de cadrer une suite. Le travail peut se faire à distance, quel que soit votre pays.
Avant de décider
- Décrire le parcours que l’équipe doit pouvoir terminer.
- Faire préciser les exclusions, frais récurrents et accès nécessaires.
- Convenir des tests de validation et de la remise du code.
- Écrire le traitement des anomalies et demandes hors périmètre.
Questions fréquentes
Un prix fixe signifie-t-il des modifications illimitées ?
Non. Le prix correspond au périmètre convenu. Les nouvelles demandes doivent être examinées et chiffrées séparément avant engagement.
Peut-on commencer si le besoin est encore flou ?
Oui, par un échange de cadrage. Un engagement de construction demande ensuite un livrable et des critères de validation assez précis pour établir le devis.