Développement logiciel managé
L’équipe qui construit est nommée, et vous savez d’où elle travaille. C’est toujours vous qui prononcez la recette.
Une équipe nommée, pas un vivier
Chaque intervention est dotée de personnes nommées, avec un rôle défini pour chacune : celle qui répond de l’architecture et de la revue de code, celles qui réalisent, et l’ingénieur qui répond des tests. Elles sont nommées au cadrage, avant toute signature, et elles restent sur l’intervention. D’où elles travaillent, et qui d’autre accède au code, se dit dans le même entretien — avant l’ouverture des accès, et non après.
Ce que « terminé » veut dire s’écrit avant la première ligne
Le périmètre, les inclusions, les exclusions et les critères de recette sont arrêtés au cadrage, et la règle qui permet de les faire évoluer est écrite en même temps. Ces critères sont ce que démontrent les tests automatisés : une livraison est mesurée au regard de ce qui a été convenu. Un périmètre bouge, sur un développement de quelque taille que ce soit ; lorsqu’il bouge, il bouge par écrit, au regard de cette règle.
Partir d’un système déjà en exploitation
Lorsque les travaux partent d’une plateforme existante plutôt que d’un dépôt vide, le premier livrable est une description écrite de ce que cette plateforme fait aujourd’hui — lue sur le système en exploitation, et non dans sa documentation. Vous validez cette description, et elle entre dans les critères de recette : les comportements dont vous dépendez doivent survivre aux travaux plutôt que d’être redécouverts après la mise en production.
Nous ne recettons pas notre propre travail
Lorsqu’une vérification indépendante est requise, elle est conduite par des personnes qui n’ont pas construit le logiciel : notre propre pratique de recette, dotée séparément, ou le tiers de votre choix. Nous travaillons avec l’un comme avec l’autre. La séparation est écrite dans le contrat plutôt que supposée.
La documentation est un sous-produit des travaux, pas une phase finale
La documentation s’écrit au fil des travaux. Les décisions sont conservées avec leur date, leur auteur nommé, les options écartées et ce qui en est résulté — dans le LightHouse Context Graph, qui traverse Foundry comme Enterprise Intelligence. Lorsque vos propres ingénieurs travaillent aux côtés des nôtres, cela figure au périmètre avec le temps que cela demande, plutôt que d’être offert de bonne grâce.
Ce que vous obtenez
- Le référentiel de développement : périmètre, critères de recette, exclusions, règles de changement
- Le code source dans vos propres dépôts, dès le premier commit
- Les suites de tests automatisées, qui vous restent
- La documentation d’environnement, de compilation et de déploiement, écrite au fil des travaux
- Le registre des décisions : datées, auteurs nommés, options écartées
- Le procès-verbal de recette, rédigé pour être signé par vous
Les limites, dites d’avance
Nous ne prononçons pas la recette à votre place. Nous ne déployons pas en production de notre propre autorité : cette approbation est la vôtre, au regard de critères arrêtés avant les travaux. Nous ne reprenons pas la maîtrise d’ouvrage : les priorités, le périmètre et les règles métier restent les vôtres, et ce que nous faisons, c’est les rendre constructibles. Et lorsqu’un périmètre appelle un acteur dont nous ne disposons pas, l’accord est nommé dans le contrat plutôt que sous-entendu.
Dites-nous ce que vous cherchez à faire développer. Une personne lit chaque message et y répond.
Les interventions sont contractées avec Onshore Technology Services, Inc., entité de droit américain. L’exécution s’appuie aujourd’hui sur des équipes constituées, principalement basées aux États-Unis ; la trajectoire africaine et son état d’avancement sont exposés sur Confiance et transparence. Confiance →