Une équipe qui porte la livraison, pas seulement les tickets
Certains travaux ne relèvent pas de la régie. Quand il n'y a pas d'équipe interne à renforcer, ou que le périmètre est un produit plutôt qu'un manque, il faut un groupe qui prend la responsabilité de le livrer et de le faire tourner ensuite.
Ce qu'une équipe dédiée signifie vraiment
Un groupe nommé, stable sur la durée de l'engagement, avec un lead responsable de la livraison et non du taux d'occupation. Les mêmes personnes mois après mois, parce que l'actif coûteux en delivery logicielle est la compréhension accumulée de votre métier, et que la rotation la détruit plus vite que n'importe quelle décision technique.
Ils portent les décisions d'architecture dans les limites que vous fixez, animent leurs propres rituels et rendent compte sur des résultats convenus au départ. Vous ne pilotez pas des individus. Vous tenez un groupe responsable d'un résultat.
Pourquoi l'externalisation déçoit souvent
Deux modes d'échec expliquent l'essentiel. Le premier est le processus parallèle : un autre board, un autre dépôt, une autre définition du fini, qui fonctionne jusqu'à l'intégration et plus après. Le second est le piège de la spécification, où le prestataire construit exactement ce qui était écrit, où l'écrit se révèle faux, et où l'avenant arrive avec un prix.
Les deux tiennent à la forme du contrat, pas à la géographie. Un forfait sur spécification figée récompense le prestataire qui en livre la lettre. Si le besoin va réellement évoluer pendant la construction, un périmètre figé garantit une dispute plus tard. Nous préférons avoir cette conversation avant l'engagement plutôt qu'au quatrième mois.
Construire, puis exploiter
L'essentiel du coût d'un système arrive après la mise en service. Une équipe qui transmet le jour du lancement et disparaît vous laisse un code que personne chez vous n'a jamais exploité, et le premier incident de production devient un exercice d'archéologie.
Nous restons par défaut sur la phase d'exploitation : supervision, réponse aux incidents, mise à jour des dépendances et la maintenance ingrate qui décide si la chose fonctionne encore dans trois ans. Si vous préférez la reprendre en interne, nous planifions la reprise comme un vrai travail avec une date, pas comme un dernier email avec un lien de dépôt.
Même journée de travail, contractualisation européenne
L'équipe travaille depuis Rabat et Casablanca en UTC+1, la même journée que Bruxelles, Paris et Amsterdam. Vous contractez avec JADEV GROUP SARL en Belgique, en euros, sous droit belge, de sorte que vos achats examinent un document fournisseur européen familier plutôt qu'un montage transfrontalier.
Quand la revue de sécurité l'exige, les ingénieurs travaillent dans votre environnement, sur votre infrastructure, sous vos contrôles d'accès et votre journalisation. Nos pratiques suivent les principes ISO/IEC 27001 avec une feuille de route vers la certification, aujourd'hui alignée sur CyberFundamentals du Centre pour la Cybersécurité Belgique. Nous ne sommes pas encore certifiés et l'audit de stade 2 est prévu en 2027.
Des formes qui fonctionnent, pas une grille tarifaire. La bonne composition dépend de si vous construisez du neuf, remplacez de l'ancien, ou maintenez en vie l'existant.
- Équipe de construction produitLead, 2 à 4 ingénieurs, QA, architecte à temps partielNouveau système, du cadrage au lancement puis à l'exploitation.
- Équipe de remplacementLead, 2 à 3 ingénieurs, spécialiste donnéesRemplacer un système legacy sans arrêter l'activité qui tourne dessus.
- Équipe run et évolution2 à 3 ingénieurs, DevOps mutualiséPorter un système vivant : incidents, dépendances, amélioration continue.
- Équipe d'intégrationIngénieurs backend, architecte d'intégrationERP, CRM et données machine qui circulent de façon fiable.
- Équipe plateforme et cloudAzure, Terraform, GitHub ActionsEnvironnements, pipelines, observabilité et maîtrise des coûts cloud.
Questions avant d'engager une équipe
- Forfait ou régie ?
- Le forfait fonctionne quand le périmètre est réellement figé, ce qui est plus rare que ne le suggèrent les propositions. Pour du produit, nous préférons une capacité fixe avec un backlog revu, parce que cela facture ce qui est stable, l'équipe, plutôt que ce qui ne l'est pas, le besoin.
- À qui appartient le code ?
- À vous, dès le premier commit, dans votre dépôt sous votre organisation. Pas de séquestre, pas de jalon de reprise qui déverrouille vos propres sources.
- Et si nous voulons internaliser plus tard ?
- C'est une issue normale et saine. La reprise se planifie comme un travail daté, avec documentation et binômage, pas comme une surprise. Un prestataire qui rend le départ difficile vous dit quelque chose sur sa confiance.
- Quelle est la taille minimale d'une équipe ?
- Deux ingénieurs et un lead est la plus petite forme qui survit à un arrêt maladie. En dessous, vous avez des individus, et il vaut mieux passer en régie, qui se facture et se pilote autrement.
- Comment rendez-vous compte de l'avancement ?
- Du logiciel qui tourne dans un environnement que vous pouvez ouvrir, à un rythme convenu au départ. Un document de statut décrivant l'avancement est un substitut à une démonstration, et généralement un mauvais.
Décrivez le système, obtenez une équipe et un chiffre
Expliquez à l'assistant de cadrage ce qu'il faut construire ou maintenir en vie. Il pose les questions qu'un ingénieur senior poserait, puis renvoie une estimation ligne par ligne avec une composition d'équipe et une date de démarrage au plus tôt.
Cadrer une équipe