Pourquoi cela compte
Les erreurs les plus coûteuses d’un projet logiciel ne se produisent pas au clavier. Elles arrivent lorsque personne n’exprime clairement ce qui doit être construit, ou quand l’architecture n’est jamais consignée. Le logiciel est aujourd’hui un actif central de votre entreprise. Sa valeur augmente à chaque extension et baisse à chaque décision floue, chaque verrouillage fournisseur, chaque patch hérité. Nous mettons les exigences sur la table avant que l’argent ne coule, et nous consignons les décisions d’architecture pour que la valeur s’accumule dans la durée - au lieu d’être consommée par sa propre complexité.
Deux standards que nous suivons
Nous ancrons chaque mandat sur deux référentiels internationaux - un pour la question « que faut-il construire ? », un pour la question « comment cela tiendra-t-il, aujourd’hui et dans cinq ans ? ».
TOGAF ADM (Architecture)
Le TOGAF Architecture Development Method maintient les quatre architectures alignées :
- Architecture d’entreprise : cartographie des capacités, value streams, exigences des parties prenantes.
- Architecture des données : modèle de domaine, propriété des données, classification de confidentialité.
- Architecture applicative : composants, interfaces, principes API-first.
- Architecture technologique : plateformes, hébergement, modèle d’exploitation.
Les décisions d’architecture sont consignées comme ADR (Architecture Decision Records) - contexte, options, compromis, conséquences. Quiconque regarde le code aujourd’hui ou dans cinq ans comprend pourquoi.
IREB CPRE (Exigences)
Nous travaillons selon le référentiel IREB d’ingénierie des exigences - le même sur lequel les praticiens certifiés CPRE sont évalués. Concrètement :
- Recueil structuré - entretiens, ateliers, observation, analyse documentaire.
- Séparation claire entre exigences fonctionnelles et non-fonctionnelles.
- Spécification sous une forme lisible par toutes les parties prenantes - cas d’utilisation, user stories avec critères d’acceptation, catalogue d’exigences non-fonctionnelles.
- Validation et vérification contre les objectifs métier et l’architecture.
- Gestion des exigences sur toute la durée du projet, avec traçabilité jusqu’aux tests.
Ce que vous obtenez
- Vision des exigences : objectifs métier, personas, diagramme de périmètre, liste hors-périmètre.
- Story map avec user stories priorisées et critères d’acceptation concrets.
- Catalogue NFR : performance, disponibilité, sécurité, conformité, ergonomie.
- Glossaire des termes métier validé avec les parties prenantes.
- Cartographie des capacités et architecture cible.
- Matrice de scoring build-vs-buy pour chaque composant majeur.
- Feuille de route de modernisation par sprints et non pas en big-bang.
- Sélection de fournisseurs et standards (OAuth, OIDC, ISO 27001, plus standards sectoriels selon besoin).
- Risques d’architecture avec mesures d’atténuation.
- Matrice de traçabilité : exigence -> décision d’architecture -> test.
Quand nous intervenons
- Vous lancez un nouveau produit et avez besoin de clarté avant le développement.
- Vous planifiez un investissement majeur et voulez savoir si l’architecture le portera.
- Un projet en cours dérape parce que les exigences sont floues ou contradictoires.
- Un système qui a pris de l’ampleur et est devenu lent et coûteux nécessite une feuille de route de modernisation sans arrêt total.
- Vous hésitez entre fournisseurs ou plateformes et voulez une évaluation objective.
- Vous voulez un regard indépendant avant un appel d’offres ou un audit.
Pourquoi Luzid
- Exigences ancrées sur IREB ; architecture sur TOGAF ADM. Deux disciplines, une même équipe - et une qualité que vous pouvez présenter à un auditeur.
- Expérience des secteurs réglementés et des plateformes SaaS.
- Nous livrons l’architecture en code, pas en slides PowerPoint - chaque décision est traçable dans le code et dans les tests.
- Nous écrivons pour que direction, conformité et développement lisent la même chose.
- Pas de verrouillage - ce que nous construisons vous appartient.