Notre approche

Le moment où tout se joue : la phase de cadrage

La phase de cadrage est le moment où un projet se gagne ou se perd. C'est là que nous établissons le périmètre du projet, identifions les choix structurants, et hiérarchisons les fonctionnalités selon leur valeur et leur criticité — avant qu'aucune ligne de code ne soit écrite. Quand le cadrage est court ou survolé, le projet paie le prix plus tard : des fonctionnalités qui ne servent pas, des règles métier mal comprises, des dépendances qui se découvrent en production. Quand il est sérieux, le projet avance ensuite avec une économie d'efforts qui se voit jusqu'à la livraison.

Cadrer un projet applicatif n'est pas dresser un cahier des charges exhaustif qui figerait toutes les décisions au démarrage. C'est isoler ce qui doit être tranché tôt — les choix structurants, irréversibles — et organiser le reste pour qu'il puisse se préciser au fil de l'avancement, sans coûter cher à modifier. Tout le travail revient à distinguer ce qui doit être stable de ce qui doit pouvoir évoluer.

Pour cela, nous nous appuyons sur trois cadres de décision éprouvés, dont la combinaison structure nos arbitrages.

Nos cadres de décision

Trois cadres de décision orientent notre travail. Chacun répond à une question précise que la phase de cadrage doit traiter.

La matrice MoSCoW classe les fonctionnalités d'un projet en quatre catégories — Must, Should, Could, Won't — selon leur criticité : ce qui doit absolument être livré, ce qui devrait l'être, ce qui pourrait l'être si le contexte le permet, et ce qui est explicitement écarté du périmètre. C'est l'outil qui prévient la dérive du cahier des charges : tout ce qui n'est pas hiérarchisé tend à devenir prioritaire à mesure que le projet avance.

La matrice RACI clarifie, pour chaque décision et chaque livrable, qui réalise, qui approuve, qui est consulté, qui est informé. Sans ce travail préalable, les responsabilités se diluent et les arbitrages se prennent par défaut. RACI ne crée pas de gouvernance là où il n'y en a pas — il rend lisible celle qui existe et révèle les zones où elle est incomplète.

Le cadre Cynefin classe les problèmes selon leur nature — simple, compliqué, complexe ou chaotique — et oriente la méthode adaptée à chacun. C'est un garde-fou contre les fausses certitudes : appliquer une méthode de problème simple à un sujet complexe produit des plans qui ne tiennent pas.

Ces trois cadres se complètent. MoSCoW arbitre la valeur, RACI clarifie les responsabilités, Cynefin oriente la méthode. Aucun ne remplace l'expertise — ils l'outillent.

Du cadrage à la mise en production : la séquence

Une fois le cadrage posé, le projet entre dans sa phase de construction. Nous travaillons par cycles courts qui livrent à chaque itération un périmètre fonctionnel utilisable. Ce rythme évite l'effet tunnel — ces mois où le projet avance sans visibilité sur ce qu'il sera — et permet à votre équipe d'ajuster ce qui ne fonctionne pas comme prévu, plutôt que de découvrir à la livraison finale un produit qui n'a pas trouvé son public.

La mise en production se prépare dès le cadrage, pas en fin de parcours. Les choix d'architecture, de structure de données et de modalités de déploiement sont posés tôt, parce qu'ils déterminent tout ce qui suit. Quand vient le moment du go-live, nous savons depuis longtemps comment l'application sera déployée, comment elle sera supervisée, comment les premières évolutions seront prises en charge.

Le projet ne s'arrête pas à la mise en service. Une application métier vit, change, s'adapte aux évolutions de l'entreprise. Notre engagement couvre ce temps long — non comme un service de maintenance générique, mais comme la continuité naturelle du travail entamé en phase de cadrage.

L'IA, accélérateur sous contrôle d'expertise

L'arrivée des modèles génératifs a changé une partie de notre travail, sans en changer la nature. Une portion croissante du code que nous produisons est aidée par l'IA — accélération réelle sur la mise en forme, la génération de tests, le passage en revue de routines bien circonscrites. Cette aide ne remplace pas le cadrage, ne pose pas les arbitrages structurants, et n'arbitre pas entre deux architectures. Elle accélère ce qui est déjà clarifié.

Sur les sujets où l'IA agentic entre en jeu — quand on confie à un modèle l'exécution autonome d'une chaîne d'opérations — nous travaillons selon le principe que nous avons développé dans notre série sur Claude Code : l'advisor pattern, un mécanisme d'organisation où un exécuteur léger consulte ponctuellement un modèle expert pour les décisions structurantes, plutôt que de mobiliser systématiquement la puissance la plus lourde. Ce principe permet de garder la maîtrise sur les coûts, sur la prévisibilité du comportement, et sur le périmètre d'autonomie effectivement donné à l'agent.

Notre position est constante. L'IA est un accélérateur dont la valeur dépend du cadre dans lequel on la déploie. Sans cadrage rigoureux en amont, elle produit vite — et vite à côté.

Trois prolongements

La méthodologie ne se déploie que sur des projets concrets, avec leurs contraintes propres. Les objets que nous construisons — portails, plateformes, outils internes — sont détaillés sur la page Applications métier sur mesure. Les choix techniques qui les portent dans la durée sont l'objet de la page Technologies. Et pour voir cette approche à l'œuvre dans des projets aboutis, nos réalisations offrent un éventail concret.