Développer un logiciel autour de votre métier, pas l’inverse.

Rarement. Une réécriture complète coûte cher, prend du temps et fait perdre des règles métier accumulées pendant des années. Dans la majorité des cas, il vaut mieux isoler la partie qui pose réellement problème, la reconstruire, et la faire cohabiter avec l'existant. Nous vous le disons quand la réécriture est la meilleure option — et aussi, plus souvent, quand elle ne l'est pas.

Oui, c'est une demande fréquente. Nous commençons par une phase de prise en main : lecture du code, cartographie des dépendances, vérification de ce qui est réellement déployé et de ce qui est testé. Cette phase donne une vision honnête de ce qui est reprenable en l'état et de ce qui demande un travail préalable.

Après le cadrage, pas avant. Une estimation donnée sans avoir compris le processus métier n'engage personne. Nous découpons en incréments livrables et nous réestimons à mesure que le périmètre se précise — un changement de priorité en cours de projet coûte beaucoup moins cher qu'un écart découvert à la livraison.

Oui. Selon les cas, nous renforçons une équipe existante, nous prenons un périmètre en autonomie, ou les deux à la fois. Le modèle se décide au cadrage et peut évoluer.

Vous partez avec le code, les données et les environnements. C'est la raison pour laquelle nous automatisons le déploiement et documentons la reprise dès le début : une passation ne doit pas être un projet en soi.