Partenaire IA en marque blanche ou co-delivery : quel modèle choisir ?

Un partenaire IA en marque blanche intervient derrière la marque du titulaire de la relation commerciale ; le client final voit principalement l'offre, les méthodes et les interlocuteurs du cabinet ou de l'agence. En co-delivery, les deux organisations sont identifiées et contribuent ensemble à la livraison, chacune sur un périmètre explicite. Ces modèles ne décrivent pas seulement une préférence de communication : ils modifient les responsabilités, les accès, la gestion du risque et le transfert de connaissances.

Le choix doit partir des entités du projet : client final, titulaire du contrat, partenaire spécialisé, données, composants techniques, livrables, support et propriété intellectuelle. Une collaboration solide précise qui décide, qui exécute, qui valide et qui répond en cas d'incident pour chacune d'elles.

En marque blanche, le partenaire spécialisé peut participer au cadrage, à l'architecture, au développement ou au support, mais sa présence est intégrée à l'identité du donneur d'ordre. Celui-ci centralise la proposition, les réunions et la restitution. Ce modèle exige une transmission particulièrement rigoureuse, car l'interlocuteur visible doit pouvoir expliquer et assumer le système livré.

En co-delivery, les expertises sont exposées au client. Le cabinet peut diriger la transformation métier tandis que le partenaire IA porte l'architecture et l'ingénierie. La transparence facilite les échanges techniques et la gestion des arbitrages, mais demande une gouvernance commune pour éviter les messages contradictoires.

• Marque blanche : continuité de marque, interface client centralisée, forte exigence de transfert.
• Co-delivery : expertises visibles, accès direct aux spécialistes, coordination commerciale partagée.
• Modèle hybride : partenaire présenté sur certains ateliers ou phases critiques, puis delivery intégré sous la conduite du cabinet.

La maturité du cabinet est déterminante. S'il possède un responsable capable de challenger l'architecture, de suivre les risques et de reprendre le support de premier niveau, la marque blanche peut fonctionner sur un périmètre maîtrisé. Si le projet touche plusieurs systèmes critiques ou exige des décisions techniques fréquentes, rendre l'expertise visible réduit les pertes d'information.

Une matrice de responsabilités doit être construite par livrable et par phase. Elle couvre la qualification, la sécurité, les données, l'architecture, le développement, la recette, la formation, la mise en production et le support. Le fait qu'un partenaire soit invisible commercialement ne réduit ni ses accès techniques ni son obligation de respecter les règles du client final.

Les accords entre partenaires doivent rester compatibles avec les engagements pris envers le client final. Une promesse de support ou de localisation des données ne peut pas être plus ambitieuse que les capacités réelles de la chaîne de sous-traitance.

La réponse dépend du type d'actif. Les comptes de production et les données du client devraient rester sous une gouvernance qui permet au client ou au titulaire autorisé de révoquer les accès. Le code spécifique, les configurations, les prompts, les évaluations et les schémas de données doivent être inventoriés. Les composants génériques antérieurs au projet peuvent rester la propriété de leur auteur, à condition que les droits d'usage et les dépendances soient clairs.

Cette cartographie évite qu'une discussion sur la propriété du « code » masque la dépendance réelle à un compte, un modèle hébergé, un jeu d'évaluation ou une connaissance détenue par une seule personne.

La protection ne repose pas uniquement sur une clause de non-sollicitation. Elle vient d'un protocole de relation clair : canaux autorisés, personnes présentes aux réunions, validation des propositions complémentaires, gestion des demandes directes et règles d'utilisation des références. En co-delivery, les partenaires doivent convenir de la manière dont une opportunité adjacente est qualifiée et attribuée.

La transparence interne est essentielle. Si le spécialiste reçoit une demande technique qui modifie le périmètre, il doit la rendre visible avant d'agir. Si le cabinet reformule une limite technique au client, le partenaire doit pouvoir vérifier que le message reste exact. Une relation commerciale durable se protège par l'alignement des incitations et la qualité de service, pas par la rétention d'information.

Le co-delivery rend naturellement visibles les décisions et permet aux équipes de travailler ensemble. Pourtant, une marque blanche peut aussi produire un bon transfert si celui-ci est prévu comme un livrable : revues d'architecture, binômage, procédures d'exploitation, ateliers de reprise et simulations d'incident. À l'inverse, la simple présence de deux logos ne garantit aucune transmission.

Le transfert doit être évalué par la capacité de l'équipe destinataire à expliquer le flux, diagnostiquer un échec, modifier une règle contrôlée et savoir quand escalader. La documentation n'est qu'un support ; la preuve réside dans l'exécution autonome d'un scénario de reprise.

Les partenaires doivent partager un registre des décisions, des risques, des changements et des incidents. Les critères de qualité sont définis avec le métier, puis traduits en tests. Les revues de sécurité portent sur les accès, les données, les journaux et les dépendances. Un calendrier de gouvernance distingue suivi opérationnel, arbitrage et communication client.

ProovUp peut intervenir selon ces différents modèles, avec un cadre adapté aux cabinets, agences et intégrateurs qui souhaitent ajouter une capacité IA sans diluer leur relation client.

Oui. Un premier projet peut être mené en co-delivery pour construire la confiance et transférer les pratiques, puis les missions récurrentes passer en marque blanche sur des périmètres connus. Le mouvement inverse est aussi pertinent lorsqu'un sujet devient plus critique ou spécialisé. La transition doit toutefois être annoncée, contractualisée et accompagnée d'une nouvelle répartition des responsabilités.

Le meilleur modèle n'est donc pas une identité fixe. C'est celui qui rend le niveau d'expertise, de risque et d'autonomie compatible avec les engagements pris envers le client final.