Notre méthode
Un bon logiciel commencepar une bonne compréhension.
Nous ne commençons pas par écrire du code. Nous commençons par comprendre le problème.
Les quatre temps
Quatre temps, et rien entre les deux.
La même équipe traverse les quatre. Personne ne récupère un dossier qu'il n'a pas suivi depuis le début.
01
Comprendre
Nous passons du temps dans vos opérations avant de proposer quoi que ce soit : les parcours réels, les contournements que vos équipes ont inventés, les contraintes que personne ne pense à mentionner. C'est là que se décide la suite.
Livrables
- Cadrage écrit
- Parcours réels
- Contraintes et risques
02
Concevoir
Architecture cible et maquettes cliquables, discutées avec les gens qui utiliseront l'outil. Ce qui est validé ici est ce qui sera développé : la conception n'est pas une intention, c'est un engagement.
Livrables
- Maquettes cliquables
- Architecture cible
- Périmètre chiffré
03
Construire
Des itérations courtes, une démonstration à la fin de chacune, et un logiciel qui tourne dès la première. Vous voyez avancer, vous pouvez corriger le cap, et vous pouvez arrêter — c'est ce qui rend l'engagement tenable.
Livrables
- Version utilisable à chaque itération
- Revue de code systématique
- Tests sur les chemins critiques
04
Faire évoluer
La mise en production n'est pas la fin du projet. Supervision, correctifs, évolutions : nous restons l'équipe qui connaît le code, et nous documentons pour que la vôtre puisse le reprendre le jour où elle le voudra.
Livrables
- Supervision et alertes
- Évolutions par tranches
- Documentation de reprise
Nos engagements
Quatre choses que nous tenons.
Clarté
Vous savez toujours où en est le projet, ce qui reste, et ce que ça coûte. Pas de rapport d'avancement qui dit tout va bien quand tout ne va pas bien.
Fiabilité
Ce que nous livrons fonctionne en production, pas seulement en démonstration. Les chemins critiques sont testés, la reprise après incident est prévue avant l'incident.
Exigence
Nous écrivons du code que votre équipe pourra lire. Une solution qui marche mais que personne d'autre ne peut reprendre n'est pas une solution livrée.
Évolution
Un logiciel utile change. Nous construisons pour que le troisième changement soit aussi simple que le premier, et nous restons pour l'accompagner.
La technologie compte. La façon dont nous travaillons avec vous aussi.
Un projet ne tient pas seulement à son architecture. Il tient à la qualité des échanges : savoir dire non, savoir annoncer un retard le jour où on le voit venir, et parler la langue de vos équipes plutôt que celle des développeurs.
« Mon travail commence là où s'arrête le vocabulaire technique : faire en sorte que chaque décision soit comprise par ceux qu'elle concerne. »
Vous avez un problème à résoudre ?
Parlons-en. Décrivez-nous la situation, et nous vous dirons par quel bout la prendre — même si la réponse est que vous n'avez pas besoin de nous.