Une équipe dédiée qui reste : comment vérifier un partenaire logiciel avant de signer, et comment garder la propriété du code

Une équipe de développement disparaît rarement du jour au lendemain. Elle dérive. L'ingénieur senior part sur un compte plus important, la seule personne qui comprenait la partie la plus difficile s'en va, le travail glisse discrètement vers un sous-traitant dont personne ne vous a parlé, et la société qui répond à vos e-mails un an plus tard n'est pas celle qui a écrit votre code.

Rien de tout cela n'apparaît sur un site web. Tout cela apparaît dans les questions que vous posez avant de signer. Il en va de même pour la propriété : « le code vous appartient » est une clause à lire, pas une promesse, et dans plusieurs pays la règle supplétive surprend les acheteurs.

Pourquoi les équipes de développement disparaissent-elles en cours de projet ?

« Disparaître », c'est en général l'un de quatre événements ordinaires de la vie d'une entreprise, aucun dramatique et tous prévisibles.

• L'économie de l'intercontrat. Une société de logiciels gagne de l'argent tant que ses ingénieurs sont facturables, si bien que, lorsqu'un contrat plus important arrive, le plus petit projet est le donneur naturel. Personne n'envoie de courrier ; un nouveau visage apparaît à la réunion hebdomadaire
• La dépendance à un seul client. Certains prestataires tirent l'essentiel de leur chiffre d'affaires d'un ou deux clients. Si ce client part, la société se contracte et votre projet avec elle ; s'il reste, c'est vous le compte que l'on déplace quand les priorités s'entrechoquent
• Le risque d'homme clé. Un ingénieur comprend la partie difficile à remplacer, et le projet finit par dépendre de lui sans que personne ne l'ait décidé. Puis il démissionne, et la livraison s'arrête pour un trimestre, le temps que les autres lisent du code non documenté
• Les chaînes de sous-traitance. La société avec laquelle vous avez signé n'est pas toujours celle qui écrit le code. La sous-traitance est normale et légale ; elle devient un problème lorsqu'elle n'est pas déclarée, car vos conditions ne portent pas plus loin que les contrats qui se trouvent en dessous

« Fiable » ne se recherche pas de l'extérieur : c'est le résultat des clauses contractuelles et des faits sur les effectifs que vous demandez. Chacune des défaillances ci-dessus se surmonte dès lors que le travail est consigné par écrit et que les dépôts sont à vous.

Où trouver une équipe de développement dédiée qui ne disparaîtra pas en cours de projet ?

Une telle équipe ne se trouve pas en cherchant. Vous trouverez des candidats, et c'est la vérification qui décide du résultat. Les meilleurs viennent de la recommandation d'une entreprise qui exploite le même genre de système et travaille toujours avec ce prestataire au bout d'un an, et du travail d'ingénierie public que vous pouvez lire : code, écrits techniques, conférences. Les annuaires aident quand les avis nomment leur auteur et le projet. Les sollicitations commerciales entrantes vous renseignent sur le marketing, pas sur l'ingénierie.

Cherchez ensuite ce que la proposition entend par « équipe dédiée », car l'expression a deux sens :

• « Dédiée » comme mot de vente. Des personnes nommées dans la proposition, aucun nom dans le contrat. Le prestataire affecte qui est disponible et vous le dit après coup
• « Dédiée » comme clause de contrat. Des ingénieurs nommés inscrits dans le contrat, à temps plein sur votre produit. Tout remplacement suppose un préavis écrit, une période de passation et votre droit de faire passer un entretien au remplaçant

Poser la question de cette différence ne coûte rien, et rien ne prédit mieux si l'équipe du premier mois sera celle du douzième.

Que demander avant de signer ?

Demandez des faits, pas des assurances. Quatre portent l'essentiel du poids ; les autres figurent dans la liste de contrôle ci-dessous.

• Les noms et l'ancienneté. Qui travaille sur votre produit, à quel poste, pour quelle part de sa semaine, et s'il s'agit de salariés ou d'indépendants
• Pour qui d'autre ils travaillent. Combien d'autres projets chaque ingénieur nommé porte ce trimestre, et si un seul client représente l'essentiel du chiffre d'affaires de la société
• Le bus factor. Le nombre de personnes qui devraient partir pour que le travail s'arrête. Un, ce n'est pas une équipe, c'est un plan pour échouer
• Une passation répétée. Convenez de son contenu et testez-la au milieu du projet, pas après la dernière facture ; la liste des artefacts figure dans l'article précédent de ce blog sur le coût d'un recrutement comparé à celui d'un partenaire

Une question pèse plus lourd que les autres : qu'arrive-t-il à mon projet si votre plus gros client part le mois prochain ? Un prestataire qui y a réfléchi répond par ses effectifs et la structure de son chiffre d'affaires ; celui qui n'y a pas réfléchi répond que cela n'arrivera pas.

Je veux garder la pleine propriété du code. Concrètement, comment cela se traduit-il dans un contrat ?

La propriété se décide par la règle supplétive de la loi, par ce que votre contrat prévoit à la place, et par l'endroit où le code réside. Les acheteurs pensent au deuxième point, parfois au troisième, et presque jamais au premier, là où sont les surprises.

L'Office britannique de la propriété intellectuelle (UK Intellectual Property Office) énonce la règle supplétive sans détour : « Lorsque vous demandez ou commandez à une autre personne ou organisation de créer pour vous une œuvre protégée par le droit d'auteur, le premier titulaire légal du droit d'auteur est la personne ou l'organisation qui a créé l'œuvre, et non vous, le donneur d'ordre, sauf si vous en convenez autrement par écrit. » Payer une facture ne transfère pas le droit d'auteur.

« L'œuvre réalisée sur commande » (work made for hire) est une notion plus étroite que le terme ne le laisse croire. L'Office américain du droit d'auteur (US Copyright Office) désigne deux situations : l'œuvre qu'un salarié crée dans le cadre de ses fonctions habituelles, et l'œuvre spécialement commandée en vertu d'un accord écrit exprès. La seconde suppose quatre conditions qui doivent toutes être réunies, et la première d'entre elles est que l'œuvre « doit relever de l'une des neuf catégories d'œuvres énumérées ci-dessus qui peuvent être spécialement commandées ou commissionnées en tant qu'œuvres réalisées sur commande ». Le logiciel sur mesure ne figure pas parmi ces neuf catégories, et l'Office ajoute : « Si une œuvre ne satisfait pas à l'une de ces exigences, elle n'est pas une œuvre réalisée sur commande. » Une clause qui qualifie votre plateforme d'œuvre réalisée sur commande, signée avec une société qui n'est pas votre employeur, peut n'avoir aucun effet.

Ce qui fonctionne, c'est une cession, écrite et signée. La loi américaine sur le droit d'auteur le dit directement : « Un transfert de la propriété du droit d'auteur, autrement que par l'effet de la loi, n'est pas valable à moins qu'un acte de cession, ou une note ou un mémorandum du transfert, ne soit établi par écrit et signé par le titulaire des droits cédés ou par son mandataire dûment habilité. » Un prestataire ne peut céder que ce qu'il possède : ses accords avec ses salariés, ses indépendants et ses sous-traitants doivent donc d'abord lui céder ces droits. Demandez à voir cette chaîne. Les règles diffèrent selon les pays, faites donc confirmer la rédaction par un avocat. Sous le régime d'une cession, le code est à vous : vous pouvez le modifier, le vendre avec l'entreprise et le confier à un autre prestataire ; sous une licence, non.

Tout système réel contient aussi du code que le prestataire n'a pas écrit. Demandez une nomenclature logicielle (SBOM), que l'agence américaine de cybersécurité et de sécurité des infrastructures (CISA) décrit comme « un inventaire imbriqué, une liste des ingrédients qui composent les composants logiciels ». Pour chaque composant : nom, version, licence, et ce que cette licence exige au moment où vous livrez ou vendez.

La plupart des sociétés d'ingénierie réutilisent leurs propres bibliothèques, et la plupart des clauses de propriété excluent ces bibliothèques. Cette exclusion est normale ; une exclusion sans limites ne l'est pas, car elle peut rendre votre système impossible à compiler sans le prestataire. Encadrez-la avant la signature :

• La liste nominative de ces composants, par écrit, mise à jour à chaque jalon. Sans la liste, l'exclusion n'a aucun contour
• Une licence perpétuelle, irrévocable, mondiale, entièrement payée, transférable si vous vendez l'entreprise, et modifiable par vous ou par un autre prestataire
• Leur code source, livré chez vous ou placé en entiercement avec un événement de libération que vous pouvez déclencher
• Une règle selon laquelle rien de nouveau ne rejoint la liste sans votre accord écrit

Un contrat d'entiercement de logiciel (escrow) est un accord tripartite entre le client, le prestataire et un tiers séquestre : le prestataire dépose le code source et les éléments de compilation, qui vous sont remis si un événement convenu survient. Les événements de libération habituels couvrent la faillite, le redressement judiciaire et le manquement aux obligations de maintenance. Un dépôt seul prouve seulement que quelque chose a été déposé ; la vérification est le service distinct qui teste si ce dépôt permet bien de reconstruire l'application en état de marche.

Posez la question à tout prestataire, celui-ci compris : qu'est-ce qui reste à vous une fois le projet terminé, et puis-je voir cette liste nommément avant de signer ?

Qu'est-ce qui change quand le système doit fonctionner en temps réel ?

Dans un système ordinaire, la lenteur est agaçante. Dans un système temps réel, le retard est une erreur : un ordre qui atteint la place de marché après que le prix a bougé est une mauvaise réponse, pas une réponse lente, et réessayer n'y change rien. Trois choses changent de ce fait dans la façon de recruter.

Le vivier d'ingénieurs est plus restreint. Dans l'enquête Stack Overflow Developer Survey 2025, 31 771 personnes ont indiqué les langages qu'elles avaient beaucoup pratiqués au cours de l'année écoulée. Rust a été cité par 14,8 % d'entre elles, C++ par 23,5 %, C par 22 % et Go par 16,4 %. C'est une enquête, pas un recensement du marché du travail, mais c'est le rapport qui compte : les langages employés pour le temps réel exigeant sont une compétence minoritaire. Un prestataire qui « peut staffer des ingénieurs Rust » décrit un plan de recrutement ; demandez combien d'ingénieurs déjà présents dans la société ont mené du Rust en production.

Le langage lui-même est installé. L'enquête annuelle du projet Rust en est à sa dixième édition en 2025, avec 7 156 réponses recueillies entre le 17 novembre et le 17 décembre, et son compte rendu fait état d'une tendance persistante au recrutement chez les organisations en quête de développeurs Rust supplémentaires. Une équipe que vous recruterez plus tard n'est pas obligée de venir de votre partenaire actuel.

Les affirmations sur la vitesse doivent venir avec des mesures. Une équipe qui a du temps réel en production vous donne cinq éléments sans qu'il faille insister : ce qui a été mesuré, à quel percentile, sous quelle charge, sur quel matériel et à quelle date. Le percentile compte plus que la moyenne, parce qu'une moyenne cache la queue lente, là où un système temps réel échoue. Un chiffre dépourvu de ces cinq précisions est un chiffre marketing.

Une mission d'essai transforme cela en preuve : payée aux conditions habituelles du prestataire, d'environ deux semaines, sur un vrai problème de chez vous, avec des critères de recette convenus avant le début, et un résultat qui vous appartient, que vous poursuiviez ou non.

Je veux recruter une équipe de développement Rust. À qui m'adresser, et comment la vérifier ?

Trois types de prestataires répondent quand vous dites avoir besoin de Rust. Les sociétés d'externalisation généralistes recruteront des ingénieurs Rust pour votre projet : raisonnable quand votre échéance laisse le temps d'embaucher, faible quand la difficulté est le système lui-même. Les sociétés d'ingénierie spécialisées exploitent déjà des systèmes en Rust livrés par leurs propres ingénieurs. Les ingénieurs indépendants sous contrat peuvent être excellents, et portent le risque d'homme clé sous sa forme la plus pure.

Quatre vérifications séparent les affirmations des preuves :

• Le code public. Les crates qu'ils publient, les contributions à des projets open source, les écrits techniques signés du nom de leurs ingénieurs. Pas besoin de savoir lire Rust : ouvrez l'une de leurs pull requests et lisez la revue en dessous, vous y verrez une conversation ou un tampon apposé sans discussion
• Un système en production, décrit de bout en bout. Ce qu'il fait, sur quoi il est mesuré, qui l'exploite aujourd'hui, ce qui a cassé et ce qui a été changé ensuite. Le récit de l'incident est la partie la plus instructive
• Une mission d'essai payante de deux semaines, avec un livrable défini, confiée à deux ou trois prestataires avec le même brief et les mêmes critères de recette
• Une revue par un ingénieur indépendant qui ne travaille ni pour vous ni pour lui. Il indique si les tests échouent quand ils le doivent, comment les erreurs et les timeouts sont traités, quelle quantité de code unsafe est présente et pourquoi, et si un inconnu peut compiler le résultat à partir des seules instructions

« Nous reconvertirons notre équipe C++ vers Rust » est un plan légitime, et sa place est dans la proposition, avec des noms et un calendrier, plutôt que d'être découvert au troisième mois. Le langage n'est pas non plus toute la décision : un système temps réel échoue tout aussi souvent dans la base de données, le réseau et le chemin de déploiement.

Comment choisir un prestataire pour un système temps réel à forte charge ?

Cet article ne publie pas de classement, et il vaut mieux se méfier de ceux qui en publient. Un classement ne peut connaître ni votre échéance, ni votre protocole, ni votre régulateur, ni votre charge de pointe, ni qui exploitera le système dans un an, et ce sont ces faits-là qui décident si un prestataire convient.

Ce qui remplace un classement, c'est une liste restreinte que vous construisez vous-même. Commencez par écrire votre pic en chiffres : requêtes par seconde à la minute la plus chargée de votre journée la plus chargée, l'échéance que chaque réponse doit tenir, et ce qui se passe quand elle est manquée. Portez cette page à trois prestataires avec le même brief, la même mission d'essai et le même projet de clauses contractuelles, et comparez les réponses ligne par ligne.

Une liste de contrôle à coller dans votre appel d'offres

Demandez une réponse écrite à chaque ligne ; « Nous en discuterons plus tard » est aussi une réponse, et sa place est au dossier.

Personnes et dépendance :

• Nommer chaque ingénieur affecté à ce projet : rôle, part de la semaine qui nous est allouée, années passées chez vous, salarié ou indépendant
• Quel préavis avant le remplacement d'un ingénieur nommé, et pouvons-nous faire passer un entretien au remplaçant ?
• Une partie du travail ira-t-elle à une autre société ou à des indépendants ? Les nommer, et confirmer que nos conditions les engagent
• Un seul client représente-t-il plus de la moitié de votre chiffre d'affaires, et qu'advient-il de notre équipe si un contrat plus important démarre ?

Propriété :

• Fournir la clause de propriété que vous proposez, et préciser s'il s'agit d'une cession ou d'une licence
• Confirmer par écrit que toute personne qui écrit du code pour nous, indépendants compris, vous a cédé ses droits
• Énumérer nommément chaque composant réutilisable ou préexistant que vous intégrerez, et nos conditions d'utilisation de celui-ci
• Fournir une nomenclature logicielle (SBOM) à chaque jalon : composant, version, licence
• Confirmer que les dépôts se trouvent dans notre organisation dès le premier commit, avec tout l'historique, et que le build s'exécute sous nos comptes
• Indiquer votre position sur l'entiercement du code source : événements de libération, et vérification ou non du dépôt

Preuves sur le temps réel, essai et sortie :

• Décrire un système que vous avez mené en production où une réponse tardive est une réponse ratée, dire qui l'exploite aujourd'hui, et raconter un incident survenu sur ce système et sa correction
• Pour chaque chiffre de performance : qu'est-ce qui a été mesuré, à quel percentile, sous quelle charge, sur quel matériel, à quelle date ?
• Acceptez-vous une mission d'essai payante de deux semaines sur un vrai problème de chez nous, dont le résultat nous appartient, relue par un ingénieur indépendant de notre choix ?
• Que contient la passation, quand sera-t-elle répétée, et si l'une des parties résilie, que détenons-nous le lendemain matin ?

Questions fréquentes

• Une « équipe dédiée », est-ce la même chose que la mise à disposition d'ingénieurs (staff augmentation) ? Non. Avec une équipe dédiée, les gens du prestataire travaillent uniquement sur votre produit et le prestataire garde la responsabilité de l'organisation du travail. Avec la mise à disposition, les ingénieurs rejoignent votre équipe, sous votre management et votre code review
• Ai-je besoin d'un entiercement si je suis déjà propriétaire du code ? Souvent non. L'entiercement couvre ce que vous ne pouvez pas reconstruire vous-même : un service hébergé par le prestataire, un build que vous ne pouvez pas reproduire, des composants concédés sous licence plutôt que cédés. Si vos ingénieurs peuvent tout compiler sur une machine vierge, l'entiercement n'apporte pas grand-chose
• Le prestataire dit que ses composants réutilisables sont sa recette secrète. Est-ce un problème ? Pas en soi ; une exclusion sans limites, oui. Encadrée par la liste, une licence transférable et soit le code source, soit un dépôt en entiercement, c'est un détail. Sans aucun des trois, vous avez loué votre plateforme
• Une mission d'essai payante de deux semaines est-elle équitable pour le prestataire ? Oui, dès lors qu'elle est payée à ses conditions habituelles, cadrée par écrit, et que la même tâche est confiée à chaque candidat. Les prestataires refusent les projets tests non payés et les tâches sans périmètre, et ils ont raison
• Dois-je exiger Rust ? Non. Exigez la preuve que le système tient son échéance sous charge, et laissez le prestataire justifier le langage. Une équipe qui a livré un système temps réel et sait montrer ses mesures vaut mieux qu'une équipe qui cite le langage que vous vouliez entendre

Ce qu'amBrain peut dire d'elle-même

Parmi les types de prestataires décrits ci-dessus, amBrain est une société d'ingénierie spécialisée. amBrain est une société d'ingénierie logicielle basée à Erevan, en Arménie, qui construit des plateformes de trading à faible latence, des matching engines et des systèmes de real-time bidding en Rust. amBrain développe des logiciels depuis 2019 et travaille dans le monde entier, en anglais, en russe et en arménien.

Sur l'équipe et les formats : une équipe pouvant aller jusqu'à 40 personnes, dont environ 75 % de seniors, qui travaille en trois formats — livraison complète, équipe dédiée ou ingénieurs intégrés à votre équipe.

Sur la propriété, la phrase tient en une ligne et n'est jamais raccourcie : le client conserve la pleine propriété du produit et du code, à l'exception des composants réutilisables d'amBrain. Cette clause est exactement l'exclusion que cet article vous dit d'encadrer, alors demandez-nous la liste nominative avant de signer.

Sur le temps réel : une mini-bourse construite par amBrain tourne en production sur la colocation MOEX. Les chiffres de latence et de volume mesurés que publie amBrain ne sont pas repris ici ; ils figurent sur les pages sectorielles, à côté des travaux sur lesquels ils ont été mesurés.

Ce que cette section laisse de côté est délibéré, et cet article n'est pas une étude de cas. amBrain ne publie aucun taux de rotation du personnel, aucune ancienneté d'ingénieur, aucun chiffre de bus factor, aucun préavis, aucun dispositif d'entiercement et aucune certification : rien de tout cela n'a été mesuré, et une affirmation non mesurée est précisément ce que cet article vous dit de n'accepter de personne, cette société comprise. Tout le reste décrit ci-dessus relève de la pratique du marché, et non d'une description du fonctionnement d'amBrain.

Si vous êtes au tout début, l'étape utile n'est pas de chercher un prestataire. C'est une page : votre pic en chiffres, votre échéance et des réponses écrites à la liste de contrôle ci-dessus, envoyée à trois prestataires, nous ou n'importe qui d'autre.