Qognis Studio · Livrable d'audit
Exemple
La question posée
Reconstruire le tunnel de paiement sur la stack actuelle, ou changer de plateforme d'abord ?
- Préparé pour
- Un client (anonymisé)
- Format
- Audit · 3.000 € forfaitaire
- Durée
- 9 jours ouvrés
- Verdict
- Pas encore
Ceci est un exemple. La structure, la profondeur et le format du verdict correspondent à ce que reçoit un client. Les constats eux-mêmes sont inventés à titre d'illustration, car les vrais audits sont confidentiels et nous ne publions pas les problèmes des autres — ni de fausses études de cas.
01 — Une question, actée par écrit
Un audit répond à une seule question, fixée dès le cadrage avant tout début de travail. Tout ce que nous trouvons qui n'aide pas à y répondre reste hors du rapport. C'est ce qui maintient un rapport à une longueur lisible plutôt qu'à soixante pages.
02 — Ce qui a été examiné
Le rapport s'ouvre sur une liste de ce que nous avons lu et exécuté. Dans cet exemple : le dépôt de code, les logs de production pour le défaut de nouvelle tentative, trois mois d'analytique du tunnel de paiement, le parcours d'achat parcouru de bout en bout, et deux sessions avec les ingénieurs responsables du code. Chaque constat cite sa source. Rien ne repose sur une impression.
03 — Constats, par conséquence
Chaque constat s'accompagne d'un niveau de gravité, des preuves qui le sous-tendent et de ce qu'il vous coûte. Ils sont classés par conséquence, et non selon l'endroit où nous les avons trouvés.
L'état du tunnel de paiement est dupliqué entre le service panier et la session de la boutique ; les deux divergent après une nouvelle tentative de paiement.
Evidence — Reproduit deux fois en préproduction. Correspond à quatre tickets de support de mai.
Consequence — Des doubles débits sont possibles en cas de nouvelle tentative. Ce défaut est à l'origine des tickets qui ont motivé l'audit.
Le rendu et les règles métier partagent une même frontière de module, de sorte que chaque changement de tarification impose une passe de régression complète.
Evidence — Historique CI : trois des cinq dernières livraisons présentent le même schéma de régression.
Consequence — Le délai de livraison est consacré à retester, pas à construire. Scinder la frontière est rentabilisé en deux cycles de livraison.
Les états de chargement et d'erreur sont incohérents entre les six vues les plus fréquentées.
Evidence — Parcours enregistré et annoté des six vues.
Consequence — La qualité perçue est en deçà de la fiabilité réelle. À corriger de manière opportuniste ; ne justifie pas un projet à part entière.
04 — Le verdict
Pas encore. Corrigez d'abord le défaut de nouvelle tentative : c'est peu coûteux, urgent, et cela reste valable quelle que soit la décision sur la stack. Changer de plateforme maintenant emporterait le défaut avec lui. Revenez à la question une fois que le volume du second marché sera réel plutôt que projeté. Lorsque le verdict honnête est un format plus léger, voire aucune mission du tout, le rapport le dit aussi — l'audit est payé pour le verdict, pas pour l'issue.
05 — Le chemin écrit
Une page, trois actions, chacune chiffrée d'après le registre public : corriger le défaut de nouvelle tentative (un Focused Build), scinder la frontière du module (un Build Sprint), réexaminer le changement de plateforme au T3 avec des volumes réels. Nous le parcourons ensemble lors de la réunion de décision, et le plan devient le périmètre de ce que le client choisit ensuite.