Nous n'avons pas encore eu à sauver un client d'un projet d'IA mal livré. Nous avons vu des systèmes mal documentés dans d'autres contextes, nous connaissons le coût réel d'en hériter, et c'est pourquoi nous traitons chaque livraison comme si le client devait continuer avec un autre fournisseur demain, même si ce n'est pas le cas.
Cette façon de penser change la conception du projet dès le départ. On n'écrit pas du code en se disant « on documentera à la fin », on ne laisse pas les credentials dans des fichiers personnels, on n'utilise pas des services que seule une personne de notre équipe sait configurer. Chaque décision technique passe par un filtre simple : si demain le client voulait emporter ce système chez lui, pourrait-il le faire ?
Cet article explique pourquoi les handovers dans des projets d'IA sont plus complexes que dans d'autres systèmes, ce que devrait inclure une livraison bien faite, et quels sont les signaux d'alerte avant de signer avec n'importe quel fournisseur qui promet des « systèmes intelligents ».
Pourquoi un handover d'IA est plus complexe qu'un autre
Dans un projet web traditionnel, un handover bien fait implique du code documenté, des accès et un README clair. La grande majorité des connaissances se trouve dans le code : si une nouvelle personne le lit, elle peut en déduire ce que fait le système et comment le maintenir.
Dans un projet d'IA, cela ne suffit pas. Le comportement du système ne se trouve pas seulement dans le code : il se trouve dans les prompts, dans les configurations du modèle, dans les outils connectés, dans les flux d'orchestration, dans les évaluations qui définissent ce qu'est une bonne réponse et dans les décisions architecturales qui ne se justifient souvent qu'avec le contexte du cas concret. Une nouvelle équipe peut lire le code et comprendre ce que fait chaque fonction, mais sans documentation supplémentaire elle ne comprendra pas pourquoi ce prompt, ce modèle ou cette séquence d'actions ont été choisis.
À cela s'ajoute un autre facteur : les systèmes d'IA sont des systèmes vivants, pas statiques. Il faut des évaluations périodiques, des ajustements quand le comportement dérive, des décisions sur quand mettre à jour les modèles. Sans transmission adéquate de cette couche opérationnelle, le système fonctionnera le premier mois et commencera à se dégrader lentement le deuxième ou le troisième, sans que le client sache pourquoi.
Un handover de qualité doit couvrir toutes ces couches, pas seulement le code.
Les six éléments d'un handover bien fait
À partir de notre expérience à construire des systèmes d'IA et de la pratique de traiter chaque projet comme s'il était livrable demain, voici les six éléments que nous considérons indispensables dans une livraison technique sérieuse :
1. Documentation technique complète. Ce n'est pas un README de trois lignes. C'est un ensemble structuré qui inclut : l'architecture du système (ce qu'il y a, ce que fait chaque partie, comment elles communiquent), les décisions techniques pertinentes (pourquoi ce modèle, pourquoi cette base de données, pourquoi cette orchestration), les runbooks opérationnels (que faire quand X échoue, comment diagnostiquer Y), et des schémas quand ils sont utiles. Si un ingénieur senior peut le lire et comprendre le système en un après-midi, c'est bien fait.
2. Accès total aux credentials et aux comptes. Tous les comptes, APIs, tokens, dépôts et services doivent appartenir au client, pas au fournisseur. Cela semble évident mais c'est le premier point où de nombreux handovers échouent : le compte de l'API est au nom du fournisseur, le dépôt est sur son GitHub personnel, le monitoring est sur un service que le fournisseur paie. Quand le client veut partir, il a un système mais n'en a pas le contrôle. Un handover bien fait inverse cette situation : le client a tout, le fournisseur n'a accès que pendant que dure la relation.
3. Tests automatisés et système d'évaluations. En IA, les évaluations sont aussi importantes que les tests unitaires en logiciel traditionnel. Elles permettent de valider que le système continue à prendre des décisions correctes quand quelqu'un touche au code, change un modèle ou ajuste un prompt. Sans évaluations, toute modification du système est un acte de foi. Un handover bien fait inclut une suite d'évaluations exécutable avec une seule commande, des datasets de test propres au cas et des critères clairs de succès.
4. Session de transfert en présentiel ou par visioconférence. La documentation est nécessaire mais pas suffisante. Une session de 2-3 heures avec l'équipe technique du client, où on explique le système, on fait des démonstrations réelles et on répond aux questions, vaut cinquante pages de documentation. C'est là que se transfère le savoir tacite : ces choses que personne n'écrit mais que tout le monde doit savoir pour opérer le système.
5. Période d'accompagnement post-livraison. Un système ne se livre jamais « fermé ». Il y a toujours des questions, des comportements inattendus ou des nouveaux besoins dans les premiers mois. Un handover bien fait inclut une période de support post-livraison —typiquement entre 1 et 3 mois— où l'équipe qui a construit le système reste disponible pour les questions. Ce n'est pas un service premium caché : c'est une partie de la responsabilité du fournisseur qui a construit le système.
6. Plan de maintenance documenté. Ce qu'il faut faire chaque semaine, chaque mois, chaque trimestre pour maintenir le système en bonne santé : réviser les évaluations, regarder les logs d'erreurs, vérifier les coûts, mettre à jour les dépendances critiques. Un plan de maintenance clair permet au client de décider s'il veut le porter en interne ou contracter la maintenance auprès de quelqu'un —le même fournisseur ou un autre. L'essentiel est qu'il puisse choisir avec information, pas avec ignorance.
Signaux d'alerte avant de signer avec un fournisseur
Si vous évaluez des fournisseurs pour un projet d'IA, voici quatre signaux d'alerte qui indiquent que vous ne recevrez probablement pas un handover décent :
Signal 1 : le fournisseur parle seulement de la démo et pas de comment elle se maintient en production. Si dans les réunions commerciales on consacre 90 % du temps à montrer comme c'est beau de voir le système fonctionner et 10 % (ou moins) à expliquer comment on l'opère, comment on le mesure et comment on le maintient, c'est le signe que sa mentalité est « livrer et partir », pas construire quelque chose qui dure.
Signal 2 : dans le budget il n'y a aucune ligne de documentation, de transfert ou de période d'accompagnement. Si le budget inclut seulement du développement et rien d'autre, cela signifie que le fournisseur pense au minimum viable pour facturer et partir. Un fournisseur sérieux considère la documentation et le transfert comme une partie intégrante du projet, pas comme un service supplémentaire.
Signal 3 : ils vous demandent de signer un contrat où seuls eux ont accès au code ou à l'infrastructure. Si la propriété intellectuelle ne reste pas clairement au client, ou si les comptes principaux restent au nom du fournisseur, ils créent une dépendance structurelle dès la minute zéro. Un fournisseur sérieux insiste pour que tout reste au nom du client dès le début.
Signal 4 : ils vous offrent une maintenance mensuelle obligatoire sans option de sortir ou de changer de mains. Il y a des fournisseurs qui structurent les contrats pour que le client reste piégé : seuls eux peuvent maintenir le système, seuls eux ont accès, seuls eux savent comment ça fonctionne. Ce n'est pas une relation commerciale, c'est une hypothèque technique. Un fournisseur sérieux offre la maintenance comme une option parmi d'autres, pas comme un besoin imposé par conception.
Pourquoi nous écrivons à ce sujet sans avoir eu à sauver personne
Nous reconnaissons que cet article ne se base pas sur l'expérience d'avoir sauvé des clients de fournisseurs antérieurs. Il se base sur le critère technique accumulé en construisant des systèmes que nous voulons voir survivre à notre relation avec le client. Chaque décision que nous prenons dans un projet passe par la question : si demain ce client voulait emporter le système, pourrait-il le faire ? La réponse doit toujours être oui.
Cette approche a un coût. Elle signifie plus de temps en documentation, plus de temps en sessions de transfert, plus de rigueur dans la gestion des accès et des comptes. Mais le coût en vaut la peine : c'est ce qui différencie un fournisseur qui traite chaque projet comme une vente de quelqu'un qui le traite comme une relation professionnelle.
Si vous évaluez des fournisseurs pour un projet d'IA, posez-leur ces questions avant de signer : à quoi ressemblerait un handover si demain nous décidions de changer de fournisseur ? Quelle documentation recevrions-nous ? Quels accès ? Y a-t-il une période d'accompagnement incluse ? Si les réponses sont vagues ou défensives, vous savez déjà ce que vous devez savoir.
Si vous voulez nous parler d'un projet concret —le vôtre ou un que vous évaluez—, écrivez-nous. Que vous ayez ou non l'intention de finir par travailler avec MindRise, une évaluation honnête de l'approche peut vous éviter des problèmes importants par la suite.