Proton, code IA et tests : la confiance se joue aussi dans les décisions internes

Proton, code IA et tests : la confiance se joue aussi dans les décisions internes

Un développeur demande quelques jours pour vérifier la sécurité du nouveau code. Sa direction veut accélérer avec l’IA. Le désaccord pourrait déboucher sur un arbitrage : quels risques tester, avec quelles preuves, avant quelle livraison ? Selon une enquête de 404 Media sur Proton, il a aussi donné lieu à des propos dévalorisants dans un canal Slack interne.

Plus une entreprise accélère grâce à l’IA, plus elle doit protéger le droit de dire : « ce n’est pas encore suffisamment vérifié ». Le sujet dépasse le choix d’un outil de code. Il touche à la façon dont une direction reçoit les objections, décide de livrer et rend sa promesse de confiance crédible. Cela ne démontre pas que les produits Proton sont compromis.

Que rapporte précisément l’enquête sur Proton ?

Dans son enquête du 29 octobre 2026, Joseph Cox indique avoir interrogé huit salariés actuels et un ancien salarié de Proton, et consulté des échanges Slack, des enregistrements de réunions et un manifeste interne sur l’IA. Il s’agit de son travail journalistique : nous n’avons pas authentifié nous-mêmes ces documents. Frandroid a repris le sujet le même jour.

404 Media rapporte qu’à la fin du mois d’août, un salarié demandait au moins quelques jours pour effectuer des tests d’intrusion, ou pentests, sur du nouveau code avant sa mise en production. Le média attribue au CEO Andy Yen cette réponse : That’s bullshit and loser thinking. Of course it’s possible to be fast and secure. Ce sont des propos internes devenus publics par l’enquête, pas une déclaration publique volontaire du dirigeant.

La seconde phrase compte : Yen affirme qu’il est possible d’être rapide et sûr. Lire cet échange comme un aveu de suppression de tous les tests serait donc abusif. Le problème managérial soulevé par les termes employés reste entier : comment faire examiner une demande de vérification sans que son auteur soit renvoyé à un manque d’ambition ?

Pourquoi le chiffre de 90 % ne répond pas à la question de la qualité

Selon l’enquête, le CTO Bart Butler a indiqué en réunion que 90 % du code écrit chez Proton en octobre l’avait été par IA. Ce chiffre ne décrit pas 90 % de toute la base de code historique. La méthode de calcul et le dénominateur ne sont pas explicités : suggestions acceptées, lignes produites ou code effectivement livré ne mesurent pas nécessairement la même chose.

Plusieurs salariés cités par 404 Media mentionnent un usage important de Claude. Cela ne permet ni d’attribuer à Claude seul la totalité des 90 %, ni d’en déduire que les emails, mots de passe ou fichiers des clients sont envoyés à Anthropic. Un outil utilisé pour développer un produit et les flux de données des utilisateurs de ce produit sont deux questions distinctes.

Le manifeste de septembre décrit, toujours selon le média, un objectif de revue de code majoritairement réalisée par IA. L’enquête rapporte aussi une vision où les humains rédigeraient les spécifications de tests que l’IA coderait et exécuterait. Ce sont des orientations rapportées, pas la preuve d’une pratique déjà universelle. L’article mentionne également des consignes de vérification du code et un salarié soulignant que les ingénieurs continuent à chercher à développer de manière sécurisée.

Pour décider d’une livraison, le dirigeant doit demander quelles preuves couvrent ce changement, pas seulement quelle part du code vient de l’IA. Une proportion de code généré ne renseigne, à elle seule, ni la couverture des risques ni la qualité de la revue.

La confiance dépend aussi de ce qu’un salarié peut contester

Proton fournit des services centrés sur la confidentialité et la sécurité. Pour une entreprise dont les clients attendent cette protection, la manière de traiter une objection technique intéresse aussi la communication : la promesse externe suppose que les désaccords pertinents puissent remonter en interne.

Le risque est un mécanisme, pas un incident démontré : si demander une vérification devient socialement coûteux, un salarié peut hésiter à soulever le prochain doute. La direction risque alors d’entendre moins d’objections sans que le produit soit devenu plus fiable. Nous ne pouvons pas établir que cette chaîne a provoqué une faille chez Proton ; elle explique pourquoi les échanges rapportés méritent une discussion au-delà du ton employé.

La réponse de Proton figure dans l’enquête. Son porte-parole y reconnaît des salariés mécontents ou anxieux, ainsi qu’une communication parfois trop abrupte ou trop lente dans l’effort d’accélération. Joseph Cox écrit que le porte-parole n’a contesté ni son récit ni sa caractérisation. Cette réponse est reproduite par le journaliste ; elle n’est pas une confirmation technique indépendante de chaque fait rapporté.

Accélérer et vérifier ne sont pas deux camps irréconciliables. Une objection peut être imprécise, un délai disproportionné, un test mal ciblé. Mais pour le savoir, il faut examiner le risque évoqué et la preuve attendue, plutôt que qualifier la personne qui les soulève.

Comment accélérer sans pénaliser la vérification ?

Une direction n’a pas besoin d’imposer le même délai à chaque livraison. Elle a besoin de critères qui rendent les décisions discutables et traçables. Voici quatre règles opératoires proposées, sans présumer des procédures réellement en place chez Proton.

• Définir ce qui autorise la livraison. Avant le développement, nommer les comportements et permissions à vérifier, les limites acceptables et les résultats attendus. « L’IA a relu le code » décrit une opération, pas son résultat.
• Rendre l’arbitrage explicite. Si la date compte davantage qu’une vérification supplémentaire, préciser ce qui est reporté, qui accepte le risque et quelle restriction accompagne la mise en production. Réduire le périmètre peut être préférable à retirer un contrôle critique.
• Documenter les objections sans punir leur auteur. Une demande doit pouvoir préciser le scénario redouté, le test proposé et la décision nécessaire. Le responsable peut la refuser, avec une raison consignée et une voie d’escalade, sans transformer le désaccord en jugement de loyauté.
• Conserver les preuves de revue et de tests. Identifier la version, les contrôles exécutés, leurs résultats et les limites restantes. Lorsque l’IA produit le code et les tests, vérifier que les tests ne reprennent pas simplement les mêmes hypothèses erronées.

Exemple illustratif, sans lien avec un incident Proton : une PME veut livrer un portail client généré avec l’IA. Le parcours de connexion fonctionne, mais un développeur n’a pas encore vérifié qu’un client ne peut pas consulter le devis d’un autre. La décision porte sur une permission précise. On peut retarder l’ouverture, limiter l’accès à un pilote ou corriger puis tester ; compter les lignes produites ne tranche rien.

Cette distinction entre démonstration et preuve vaut aussi en amont : un test utilisateur de prototype IA vérifie la compréhension du parcours, pas l’isolation des données entre clients. Les deux vérifications répondent à des questions différentes.

Que doit demander un dirigeant avant de dire « on livre » ?

Trois questions suffisent pour ouvrir le bon échange : qu’avons-nous vérifié sur cette version ? Que reste-t-il d’incertain ? Qui décide de l’exposition aux utilisateurs, avec quelle possibilité de retour arrière ? Les réponses peuvent être courtes. Elles doivent être concrètes.

Dans notre framework de développement MVP, les critères définis au cadrage alimentent les tests et le CI/CD, c’est-à-dire les contrôles automatisés de livraison. Le déploiement contrôlé puis la mesure permettent ensuite de corriger sur des observations réelles. L’IA peut accélérer plusieurs étapes ; elle ne dispense pas de nommer la preuve exigée pour passer à la suivante.

La leçon de l’enquête n’est pas d’interdire le code IA, ni de conclure à une compromission de Proton. C’est de prendre au sérieux le coût d’une objection rendue difficile. Une équipe capable de produire plus vite doit aussi pouvoir signaler, sans se discréditer, ce qu’elle n’a pas encore suffisamment vérifié.

Vous développez avec l’IA et les critères de livraison restent flous ? Say Digital peut vous aider à cadrer les exigences, les tests et le déploiement de votre prochaine version. Échangeons sur votre chaîne de livraison.

Sources et limites

• Joseph Cox, 404 Media, 29 octobre 2026 : enquête originale et réponse du porte-parole reproduite dans l’article, liées plus haut.
• Frandroid, Cassim Montilla, 29 octobre 2026 à 17:07 : reprise française, liée plus haut.

Sources relues le 30 octobre 2026. Vérification ciblée complémentaire du blog officiel de Proton et de la page d’Andy Yen : aucune réponse distincte identifiée dans les surfaces consultées, ce qui ne prouve pas son absence ailleurs. Cet article est une analyse de management et de livraison logicielle, pas un audit technique de Proton. Les sources consultées ne démontrent ni fuite de données clients, ni compromission des produits, ni disparition de tous les tests.