IA : vérifier les start-up et protéger les lanceurs d’alerte
Comment évaluer une start-up IA sans se fier aux démonstrations, et que peuvent faire les salariés face à des NDA qui étouffent les alertes ?
Start-up IA : vérifier les promesses et protéger les lanceurs d'alerte
Une démo convaincante ne veut pas dire, à elle seule, que l'entreprise maîtrise vraiment la technologie qu'elle vend. En intelligence artificielle, on peut facilement donner l'impression du « sur-mesure » en s'appuyant sur un modèle tiers, sur des étapes faites à la main, ou sur des capacités qui n'existent pas encore à grande échelle. Du coup, pour un investisseur, un client ou un partenaire, trier le vrai de la mise en scène demande plus qu'un rendez-vous commercial.
C'est ce que dit Tyler Shultz, ancien salarié de Theranos et lanceur d'alerte dans l'affaire de la fraude aux tests sanguins. Dans un entretien accordé au podcast PST du San Francisco Standard, il explique que l'IA rend la vérification des promesses particulièrement difficile. Il met aussi en garde contre certains accords de confidentialité et de non-dénigrement, qui, selon lui, peuvent décourager des salariés de signaler des risques. Il estime que ces clauses seraient « probablement illégales » - mais cette formulation reste une appréciation, pas une conclusion juridique.
Le sujet est concret : investir sans regarder la technologie peut financer des capacités qui n'existent pas. Et un salarié, mal informé, peut finir par croire qu'un NDA lui interdit de parler à un avocat ou à une autorité. Voici donc une façon d'évaluer ces deux risques, avec des repères utilisables par les entreprises, et cohérents avec le droit français et européen.
Pourquoi une entreprise d'IA peut-elle être difficile à vérifier ?
Une démonstration n'est pas une preuve de capacité
Tyler Shultz pose le problème simplement : il est parfois dur de savoir si le produit repose sur une innovation propre ou s'il s'agit surtout d'une interface construite autour d'un modèle déjà disponible. Une entreprise peut proposer une expérience utilisateur fluide sans avoir, en interne, développé le modèle, les données ou l'infrastructure qui justifieraient ses affirmations commerciales.
Et ce n'est pas forcément de la fraude. Partir d'API existantes peut être un choix rationnel : ça accélère le lancement, limite les coûts au démarrage et permet de tester la demande. Le vrai risque apparaît quand le discours laisse entendre que l'entreprise a une technologie différenciante, autonome, ou déjà industrialisée - alors que ce n'est pas le cas.
Une démo montre souvent un scénario sélectionné, préparé, dans des conditions « propres ». Elle ne dit pas, par exemple, quel est le taux d'erreur, comment le système réagit sur des données bizarres ou inhabituelles, quelle est la dépendance à un tiers, le coût par requête, ni même le niveau de travail humain nécessaire pour obtenir le résultat. Or, en production, tout ça change la donne - et souvent, la marge aussi.
L'IA complique la vérification sans rendre toute innovation suspecte
Dans un logiciel « classique », on peut parfois tester une fonction et obtenir un résultat assez stable. Avec les systèmes génératifs, la production varie : on peut obtenir des réponses plausibles mais fausses, ou très dépendantes du contexte. Résultat : réussir une présentation ne permet pas de déduire la fiabilité globale du système.
La difficulté augmente quand l'entreprise invoque des « données propriétaires » ou des secrets commerciaux pour refuser tout examen. Une part de confidentialité est légitime. Mais elle ne devrait pas rendre impossible une évaluation indépendante, encadrée. Le bon sujet n'est pas d'exiger un accès public à des informations sensibles : c'est de demander des preuves vérifiables, avec des règles de confidentialité adaptées.
Le précédent Theranos rappelle ce que coûte la confiance aveugle
Shultz dit que les investisseurs de Theranos ont été trompés, mais aussi qu'un manque de vérifications leur a laissé une influence et une crédibilité très importantes. Il critique notamment l'idée qu'une réunion informelle d'une trentaine de minutes puisse suffire à justifier un investissement de 100 000 dollars. À l'époque, Elizabeth Holmes a levé des sommes considérables avec des promesses techniques qui, elles, n'ont pas résisté à l'examen.
Attention : comparer ne veut pas dire conclure. Les technologies, les marchés et les cadres réglementaires ne sont pas les mêmes. Mais la leçon demeure : quand une promesse est difficile à vérifier de l'extérieur, la diligence doit être plus structurée. Le nom du fondateur, la qualité du récit et la pression à investir ne remplacent pas des éléments techniques concrets.
Un NDA peut-il empêcher un salarié de lancer une alerte ?
Ce que dénonce Tyler Shultz
Shultz affirme que certains accords de confidentialité et de non-dénigrement signés par des salariés de laboratoires d'IA seraient trop contraignants et pourraient être illégaux. Il raconte qu'à Theranos, plusieurs NDA lui auraient fait croire qu'il ne pouvait pas parler à un avocat ni à un régulateur. Il dit alors avoir utilisé un pseudonyme et une adresse électronique fictive pour contacter les autorités.
Son témoignage pointe surtout un effet pratique : même quand quelqu'un a un droit d'alerte, la formulation du contrat peut décourager de l'exercer. Le texte, les consignes reçues, la hiérarchie, et la crainte de perdre son emploi pèsent dans la décision de parler. Et la protection juridique devient faible si le salarié ne sait pas qu'elle existe, ou s'il pense qu'il s'expose automatiquement à des poursuites.
Le débat dépasse le cas Theranos. Le texte source mentionne aussi des préoccupations de parlementaires américains autour de chercheurs licenciés chez OpenAI, ainsi que des témoignages d'anciens salariés lors d'une audience à New York. Mais ces éléments ne suffisent pas, à eux seuls, à établir qu'une entreprise (ou un NDA) a enfreint la loi : on est encore sur des signaux, pas sur des conclusions.
Le droit dépend du pays, du contrat et des faits
Dire qu'un NDA est « probablement illégal » ne vaut pas comme règle générale. Les États-Unis comme l'Europe ont des cadres variables selon la juridiction, le statut de la personne, le contenu de l'accord et la nature des informations concernées. Une clause de confidentialité peut protéger des secrets commerciaux légitimes, sans pour autant neutraliser automatiquement tous les droits ou toutes les obligations prévues par la loi.
En France, la protection des lanceurs d'alerte repose notamment sur la loi dite Sapin II, modifiée en 2022, ainsi que sur la transposition de la directive européenne relative à la protection des personnes qui signalent des violations du droit de l'Union. Ces dispositifs encadrent les signalements et limitent certaines représailles quand les conditions légales sont réunies. Ça ne veut pas dire, automatiquement, que toute divulgation publique est couverte, ni que chaque désaccord professionnel se confond avec le statut de lanceur d'alerte.
Autre point : la confidentialité et l'alerte ne sont pas la même chose. Un salarié peut détenir des informations personnelles, commerciales ou sensibles qu'il faut encadrer et sécuriser. La bonne démarche est souvent de demander un avis juridique adapté aux faits et au pays, plutôt que de supposer qu'un NDA interdit toute parole - ou, à l'inverse, qu'il peut être ignoré sans risque.
Les entreprises ont intérêt à ne pas confondre secret et silence
Un accord sérieux doit dire clairement quelles informations sont protégées et quels usages sont autorisés. Les politiques internes doivent aussi préciser comment remonter un signalement, comment saisir les autorités compétentes, et quelles protections s'appliquent. Une clause ambiguë, trop large, ou accompagnée de menaces peut produire l'effet inverse de celui recherché : moins de remontées internes, et découverte plus tardive des problèmes.
Dans les équipes qui développent des systèmes d'IA, cette distinction compte particulièrement. Quelqu'un qui observe des évaluations falsifiées, un risque de sécurité ou une utilisation non conforme des données doit savoir à qui remonter. Une organisation qui traite toute critique comme une « fuite » fragilise sa capacité à corriger avant qu'un client, un régulateur ou le public ne découvre le problème.
Que peuvent faire concrètement investisseurs et salariés ?
Pour les investisseurs : inscrire les vérifications dans le processus
Commencez par ne pas attendre la fin. Les questions de données, de sécurité et de dépendances doivent être posées tôt, avant que l'enthousiasme et le calendrier de financement compliquent la vérification. Une équipe d'investissement peut répartir les rôles : expertise technique, analyse du marché, conformité, et examen des risques opérationnels.
Ensuite, il faut faire le tri entre les types de preuves. Une démo prouve un fonctionnement « sur un moment ». Un pilote avec un client informe sur l'intégration et l'usage. Des mesures reproductibles sur un jeu de cas documenté donnent une idée plus solide de la performance. Et des éléments comme des contrats, ou des journaux d'incidents, aident à comprendre comment ça tourne réellement. Aucun élément ne suffit seul : leur cohérence compte.
Enfin, les contrats et les plans de suivi doivent prévoir des points de contrôle. Les performances annoncées, les coûts d'inférence, la dépendance aux fournisseurs et la gestion des incidents évoluent avec le produit. Vérifier une fois ne garantit pas que tout sera identique six mois plus tard.
Pour les salariés : se protéger sans improviser
Si vous pensez avoir vu un risque sérieux, évitez de conclure automatiquement que votre NDA vous interdit de demander conseil. Cherchez une consultation juridique confidentielle et regardez quelles voies d'alerte existent dans votre pays. En France, le Défenseur des droits peut orienter si vous hésitez sur votre statut ou sur les protections applicables ; un avocat peut analyser les clauses et les faits spécifiques à votre situation.
Côté pratique, gardez une trace factuelle de ce que vous avez observé, sans emporter ni diffuser des données auxquelles vous n'avez pas droit. Notez les dates, les décisions, les canaux utilisés, et privilégiez les mécanismes prévus pour recevoir les alertes. Comment documenter et transmettre dépend du dossier : un conseil professionnel réduit les risques pour vous et aussi pour les personnes concernées.
Shultz rappelle que certains avocats acceptent des dossiers de lanceurs d'alerte avec des honoraires conditionnés au résultat. Ce n'est ni systématique ni uniformément disponible selon les pays et les affaires. L'intérêt, surtout, est de rappeler qu'une personne ne devrait pas décider seule, sous pression, qu'elle n'a aucun recours.
Pour les entreprises : rendre les alertes utilisables
Un dispositif crédible ne se réduit pas à une adresse générique. Il faut préciser qui reçoit les alertes, comment sont traités les conflits d'intérêts, quelles garanties de confidentialité s'appliquent, et comment sont prévenues les représailles. Il faut aussi former les managers : la première réaction à une alerte conditionne souvent la suite - enquête sérieuse ou étouffement.
Dans une entreprise d'IA, les alertes peuvent porter sur les données d'entraînement, les résultats de tests, la sécurité, les usages clients, ou même la communication commerciale. Traiter un signalement au sérieux, ce n'est pas présumer que tout est fondé : c'est l'enregistrer, vérifier les faits avec les bonnes personnes, et documenter la décision. Une entreprise qui sait écouter tôt se donne une vraie chance de corriger avant que le défaut ne devienne une crise.
À retenir : une démonstration ne remplace pas une évaluation indépendante ; un NDA ne doit pas être lu comme une interdiction absolue de signaler un risque ; et la diligence doit couvrir à la fois la technologie, son modèle économique et sa gouvernance.
Conclusion : la confiance ne remplace pas la vérification
L'avertissement de Tyler Shultz concerne deux problèmes qui se renforcent : des promesses technologiques difficiles à vérifier, et des dispositifs de confidentialité qui peuvent décourager les personnes qui voient les problèmes de l'intérieur. Dans les deux cas, le risque vient moins de l'IA elle-même que d'un manque de contrôles adaptés.
Pour les investisseurs et les clients, la réponse passe par une diligence proportionnée : des tests, des dépendances explicites, et une économie vérifiée dans des conditions réelles. Pour les entreprises, il faut un cadre de confidentialité clair et des canaux d'alerte vraiment utilisables. Pour les salariés, l'idée est simple : ne pas interpréter seul un NDA, et demander conseil avant d'agir.
En pratique : plus une promesse est difficile à vérifier, et plus une erreur peut coûter cher, moins on peut se contenter de la confiance. Vérifiez ce qui peut l'être, documentez les limites, et donnez aux alertes un chemin sûr jusqu'aux personnes capables de traiter le problème.
Comment mener une due diligence utile sur une start-up IA ?
Commencer par reformuler la promesse en critères testables
Avant d'évaluer le produit, traduisez ce que l'entreprise dit en questions vérifiables. Si elle promet d'automatiser le traitement de factures, demandez quelles catégories de documents sont couvertes, quel niveau de précision est atteint, et quelle intervention humaine reste nécessaire. Si elle annonce « réduire de moitié » le temps de traitement, il faut préciser : réduit par rapport à quoi, sur quel périmètre, et sur quelle période.
Un bon test doit inclure des cas représentatifs, mais aussi des exceptions. Dans un contexte français, ça peut vouloir dire : documents mal numérisés, formats propres à différents fournisseurs, et données qui respectent les règles internes de protection. L'objectif n'est pas seulement de mesurer les réussites : il faut aussi regarder les erreurs qui coûtent cher - paiement incorrect, décision injustifiée, fuite de données, ou reprise manuelle.
Examiner la chaîne technique et les dépendances
L'investisseur ou le client doit comprendre ce que l'entreprise a réellement construit. Les questions portent notamment sur les modèles utilisés, les fournisseurs cloud et d'API, les droits d'utilisation des données, la possibilité de changer de fournisseur, et les mesures de sécurité. S'appuyer sur un « gros modèle » externe n'est pas un défaut en soi. Le problème, c'est quand l'entreprise ne sait pas en évaluer les conséquences financières et opérationnelles - ou quand elle les dissimule.
Il faut aussi demander comment les versions sont évaluées et déployées. Une équipe sérieuse doit pouvoir expliquer ses tests, les limites connues, comment les incidents sont suivis et comment on revient à une version antérieure si besoin. Une réponse honnête sur les limites vaut souvent mieux qu'une promesse vague de performance exceptionnelle.
Évaluer l'économie du produit en conditions réelles
Un prototype peut impressionner et rester non rentable. La diligence doit donc couvrir le coût réel : appels aux modèles, hébergement, annotation des données, support, et vérifications humaines. Et il faut tester ce qui se passe quand le volume augmente : un système utilisable par dix personnes peut devenir trop lent ou trop cher dès qu'un grand compte arrive.
Pour un comité d'investissement, une grille courte aide à organiser l'examen :
Cette grille ne remplace pas l'expertise technique, juridique ou financière. Mais elle évite qu'une seule démo - ou la confiance dans le fondateur - fasse le travail à la place de l'analyse. Le niveau de vérification devrait monter avec le montant investi, la sensibilité des données, et les conséquences d'une défaillance.