01
Premier plan
Ce qui reste, ce qui change
Reconstruire, encapsuler ou retirer, décidé par composant. Ce qui doit rester identique est écrit. Chaque changement voulu aussi.
Modernisation
Un nouveau cœur sous les écrans que vos clients utilisent déjà.
L'activité ne peut pas s'arrêter. Le système doit pourtant changer. Un essaim reconstruit le cœur en parallèle, pendant qu'un ingénieur responsable s'assure que rien de ce dont vos clients dépendent ne casse.
Pourquoi les réécritures s'enlisent.
L'équipe gonfle, l'échéance recule, et l'ancien système continue de tourner parce que personne ne fait confiance au nouveau.
Production
Le système gagne de l'argent chaque jour. Un programme classique lui demande d'attendre dix-huit mois.
Régression
Personne ne peut lister ce qui ne doit pas casser. Alors tout est testé à la main, ou pas du tout.
Dérive
La réécriture devient un second produit, avec son propre backlog. L'ancien reste celui que les clients utilisent.
Pendant l'exécution
Ce que vous voyez à tout moment.
Où ça vit
Votre cloud. Votre dépôt.
- 01 Application Web, mobile et rapports tournent dans vos comptes.
- 02 Dépôt Le premier commit est déjà le vôtre.
- 03 Hébergement Nous n'hébergeons jamais. Il n'y a rien à dénouer quand nous partons.
Le travail
Le déroulement, dans l'ordre.
02
Contrats
Verrouiller les interfaces
Les API, les événements et les rapports sont fixés d'abord. L'essaim construit dessus. Le nouveau cœur ne peut pas les inventer plus tard.
03
Reconstruction parallèle
Le plus risqué d'abord
Les parcours dont la casse vous coûterait le plus sont reconstruits d'abord, chacun avec des tests qui prouvent que l'ancien comportement tient.
04
Bascule
Éteindre l'ancien cœur
Le trafic bascule composant par composant. L'ancien chemin n'est coupé que lorsque votre équipe a accepté les fichiers.
01
Contrôles
Ce qui ne doit pas casser est un test, pas un espoir.
Chaque parcours client nommé reçoit un test avant que l'essaim ne touche au cœur. Les tests tournent à chaque modification. Un manquement arrête la mise en production, quelle que soit la date.
Contrôles
Ce qu'un contrôle en échec bloque
- 01 Mise en production Une construction en échec n'est pas livrée. Pas même en préproduction.
- 02 Production Un contrôle de sécurité ou de performance en échec ne passe pas en production.
- 03 Bascule Pas de bascule sans rollback écrit et répété.
02
Risque
Vous ne menez pas la réécriture pour ensuite porter chaque échec.
Un ingénieur responsable porte le résultat jusqu'à l'acceptation par votre équipe. Pas un projet que vous pilotez, pas un prestataire que vous relancez.
Qui le porte
Le risque de livraison a un seul responsable
- 01 Heures Plusieurs prestataires, plusieurs mains. Chaque raté est pour vous.
- 02 UNIT01 Un ingénieur responsable porte le résultat jusqu'à votre acceptation.
- 03 Production Vous décidez quand le trafic bascule. Nous faisons en sorte que vous le puissiez.
03
Acceptation
L'ancien cœur reste jusqu'à l'acceptation par votre équipe.
Un déploiement n'est pas une passation. Manuels d'exploitation, supervision et risques ouverts sont d'abord dans votre dépôt. Ensuite l'ancien cœur s'éteint.
Acceptation
Ce qui est dans votre dépôt avant que vous ne signiez
- 01 Tests Écrits avec le code. Qui tournent dans votre pipeline.
- 02 Manuels d'exploitation Comment l'exploiter. Qui appeler. Comment revenir en arrière.
- 03 Risques Chaque point ouvert a un responsable. Rien n'est découvert plus tard.
Dans le premier plan
Ce qui est écrit avant le démarrage.
Le premier plan nomme chacun de ces points. C'est un document : vous l'acceptez, le modifiez, ou le refusez.
Carte
Reconstruire / encapsuler / retirer
Décidé par composant dans le premier plan. Pas découvert au sixième mois.
Contrôles
Ce qui doit encore fonctionner
Les parcours nommés ont des critères de réussite avant que nous ne touchions au cœur. Ce sont des tests, pas une liste.
Changements
Liste des changements voulus
L'acceptation nomme ce qui est nouveau. Un changement non listé est un défaut.
Ingénieur responsable
Une personne nommée
L'ingénieur qui mène est nommé au contrat. Vous rencontrez cette personne avant de signer.
Fichiers
Dans votre dépôt
Code, tests, manuels d'exploitation, supervision et risques ouverts. Là avant l'acceptation.
PI
Code et marque restent chez vous
Cédés par contrat. Nous n'hébergeons jamais le produit, et nous ne le gardons pas.
Questions que l'on nous pose
Questions fréquentes.
01
Pourquoi plus vite que notre propre équipe ?
Votre équipe a un quotidien. Un essaim, non. Il reconstruit les composants et écrit leurs tests en parallèle, et l'ingénieur responsable le maintient dans les interfaces que vous avez verrouillées.
02
Est-ce un rafraîchissement d'interface ?
Seulement si le risque est dans l'interface. Le plus souvent, il est dans les services et les données. Nous le disons dans le premier plan.
03
Gardez-vous chaque comportement ?
Nous gardons ce que vous nommez, et nous le prouvons par des tests. Le reste est un changement listé, que vous acceptez.
04
Peut-on garder des parties de l'ancien système ?
Oui. Encapsuler et retirer sont des choix à part entière, pas des échecs.
05
Et si l'ancien prestataire reste ?
Très bien, tant que le résultat a un seul responsable. Dès la première semaine, nous dirons si le partage est dangereux.
06
Quand l'exploitation le reprend-elle ?
Quand elle accepte les fichiers dans votre dépôt. Pas au moment d'un déploiement.
Autres missions
La même façon de travailler, sur un autre système.
Étape suivante
Dites-nous ce qui doit entrer en production, et quand.
Vous recevez un premier plan : ce que «terminé» signifie, dans vos mots, ce que ça coûte et quand. La décision vous appartient.