Analyse & architecture
Cadrer et architecturer avant de construire.
Beaucoup de projets échouent avant la première ligne de code : besoin mal posé, périmètre irréaliste, architecture choisie par habitude. Une phase d'analyse sert à prendre des décisions documentées et à savoir ce que l'on ne fera pas. Elle n'est pas toujours nécessaire, et nous vous le dirons.
Quand une phase d'analyse est utile
Quand une décision structurante est en jeu et que les avis divergent.
Vous hésitez entre acheter une solution du marché et développer sur mesure.
Un projet a été chiffré par plusieurs prestataires avec des écarts que personne n'explique.
Vous devez remplacer un système central et vous ne savez pas par où commencer.
Plusieurs équipes ont des visions différentes du même besoin.
Un projet précédent s'est arrêté en cours de route et vous voulez comprendre pourquoi avant de relancer.
Vous devez présenter un dossier d'investissement et vous avez besoin de chiffres défendables.
Ce que couvre une analyse
Comprendre ce qui existe, poser ce qui est réellement demandé, puis trancher.
Comprendre l'existant
- Cartographie des applications, des flux et des dépendances
- Lecture du code et de l'infrastructure en place
- Règles métier enfouies dans les outils actuels
- Points de fragilité : dépendances non maintenues, savoir concentré sur une personne
Poser le besoin
- Entretiens avec les utilisateurs réels, pas seulement les prescripteurs
- Description des processus tels qu'ils sont, avant ce qu'ils devraient être
- Distinction entre exigences, préférences et habitudes
- Priorisation explicite, y compris de ce qui est hors périmètre
Décider
- Comparaison argumentée des options, y compris celle de ne rien changer
- Choix d'architecture documentés avec leurs contreparties
- Estimation des coûts de construction et d'exploitation
- Trajectoire par étapes plutôt que projet monolithique
Ce qu'une analyse fait reculer
Chaque étape retire de l'inconnu avant que la première ligne de code ne soit écrite. C'est le moment où les décisions coûtent le moins cher à changer.
- 01
Problème métier
Le symptôme, avant toute solution
- 02
Processus & utilisateurs
Ce qui se passe réellement, contournements compris
- 03
Périmètre
Ce qui entre, et surtout ce qui n'entre pas
- 04
Architecture
Les choix structurants et leurs contreparties
- 05
Priorités
L'ordre de construction et ses dépendances
- 06
Solution à construire
Un projet chiffrable, découpé en étapes
- 01
Problème métier
Le symptôme, avant toute solution
- 02
Processus & utilisateurs
Ce qui se passe réellement, contournements compris
- 03
Périmètre
Ce qui entre, et surtout ce qui n'entre pas
- 04
Architecture
Les choix structurants et leurs contreparties
- 05
Priorités
L'ordre de construction et ses dépendances
- 06
Solution à construire
Un projet chiffrable, découpé en étapes
L'incertitude ne tombe jamais à zéro. L'objectif est qu'elle soit assez basse pour engager un budget sans parier.
Quand une analyse n'est pas nécessaire
Facturer une phase d'étude sur un besoin déjà clair n'apporte rien à personne.
- Le besoin est déjà cadré
- Si le processus est compris, le périmètre stable et la décision prise, passez directement à la construction. Une étude ne fera que retarder la première version utile.
- Le périmètre est petit
- Sur un projet court, une étude préalable peut coûter plus cher que de construire une première version et de l'ajuster à l'usage.
- La décision est déjà prise
- Quand le choix est arrêté pour des raisons qui ne sont pas techniques, une analyse ne sert qu'à l'habiller. Nous préférons le dire plutôt que de produire un document de justification.
Comment se déroule une mission d'analyse
Une analyse est courte et bornée : la date de restitution est fixée avant de commencer. Si elle dure plus longtemps que la première étape du projet qu'elle prépare, elle a raté son objectif.
- 01
Cadrer la question
Quelle décision devez-vous prendre, pour quand, et avec qui ? Sans cette question, une analyse produit un document sans destinataire.
- 02
Collecter
Entretiens, lecture du code et des données, observation des processus réels. Nous parlons aux personnes qui utilisent les outils, pas seulement à celles qui les commandent.
- 03
Confronter les options
Chaque option est évaluée avec ses coûts, ses risques et ce qu'elle interdit pour la suite. Y compris l'option de ne rien changer.
- 04
Restituer
Une restitution orale devant les décideurs, un document qui tient sans nous, et une recommandation assumée.
Ce qui peut être produit
Tout n'est pas nécessaire sur chaque mission. Le livrable se décide au cadrage, selon la décision à prendre et la personne qui la prendra.
- 01
Cartographie de l'existant
Ce qui tourne réellement, ce qui dépend de quoi, et ce qui n'est plus maintenu.
- 02
Dossier de décision
Les options envisagées, leurs contreparties et une recommandation motivée.
- 03
Architecture cible
Le schéma visé et, surtout, le chemin réaliste pour y arriver par étapes.
- 04
Estimation chiffrée
Coût de construction et coût d'exploitation, avec les hypothèses qui les sous-tendent.
- 05
Feuille de route
Un découpage en étapes livrables, avec les dépendances et les risques identifiés.
- 06
Cahier des charges
Quand vous devez consulter le marché, un document qui permet des réponses comparables.
Comment nous intervenons
Une analyse se mène en mission courte. Elle peut déboucher sur un projet, sur un accompagnement de vos équipes, ou sur rien du tout si c'est la bonne conclusion.
Consultance & renfort d’expertise
Nos consultants rejoignent votre équipe pour apporter les compétences dont vous avez besoin : développement, analyse fonctionnelle, analyse technique, business analysis ou architecture.
En savoir plusProjet sur mesure
Nous prenons la responsabilité de l’ensemble : analyse, conception, développement, intégration, livraison et évolution.
En savoir plus
Cas d’usage liés
Moderniser un logiciel métier
L’application fonctionne encore mais devient coûteuse à maintenir, difficile à faire évoluer et dépendante de quelques personnes.
Automatiser un processus métier
Les mêmes informations sont ressaisies plusieurs fois, les validations passent par e-mail et personne ne sait où en est un dossier.
Connecter des systèmes qui ne se parlent pas
Votre ERP, votre CRM et vos outils métier contiennent chacun une partie de la vérité, sans échange fiable entre eux.
Questions fréquentes
Peut-on faire une analyse sans vous confier le développement ensuite ?
Oui, et c'est fréquent. Le livrable est conçu pour être utilisable par n'importe quelle équipe, y compris vos développeurs internes ou un autre prestataire. Un dossier qui n'est exploitable que par son auteur n'est pas un livrable.
Que se passe-t-il si votre recommandation est de ne rien faire ?
Nous la rendons quand même. Certaines situations se règlent par un changement de processus, un paramétrage, ou l'abandon d'un projet mal posé. C'est un résultat de mission, pas un échec.
Faut-il un cahier des charges avant de vous contacter ?
Non. Beaucoup de demandes arrivent sous forme de symptôme : « nos équipes perdent du temps », « ce système ne tient plus ». C'est un point de départ suffisant. Un cahier des charges écrit trop tôt fige souvent une solution avant d'avoir posé le problème.
Travaillez-vous avec un prestataire déjà en place ?
Oui. Une analyse n'a pas vocation à disqualifier l'équipe existante. Dans plusieurs situations, la conclusion est qu'il faut clarifier le périmètre ou la priorisation, pas changer d'intervenant.
L'analyse inclut-elle une estimation budgétaire ?
Elle peut l'inclure, à condition que les hypothèses soient écrites. Une estimation sans hypothèses explicites ne se défend pas devant un comité et ne résiste pas au premier imprévu.
Parlons de la décision à prendre
Dites-nous quel arbitrage vous bloque. Nous vous dirons si une phase d'analyse est justifiée, et ce qu'elle devrait produire.