IA au travail : Proton évalue ses équipes et ses pratiques
Proton prévoit de réinterroger des salariés sur leur usage de l’IA. Enjeu : distinguer adoption réelle, qualité du travail et risque de décisions injustes.
Proton veut réévaluer ses équipes à l'ère de l'IA : ce que cela change
Faire de l'IA un outil de travail, ce n'est plus seulement « tester un assistant de code » ou automatiser deux tâches. Chez Proton, l'adoption de l'IA semble aussi devenir un sujet d'évaluation professionnelle. D'après 404 Media, l'entreprise suisse derrière Proton Mail prévoit d'interroger certains salariés sur la façon dont ils utilisent ces outils - avec, potentiellement, des conséquences sur leurs rôles et sur la poursuite de leur contrat.
L'histoire remet aussi une question au centre : comment accélérer sans transformer l'activité mesurée en proxy automatique de la qualité du travail ? La direction de Proton assure qu'il ne s'agit pas d'un plan de licenciements. Son argument : la pénurie de compétences, et la nécessité d'accompagner les équipes. Mais les éléments rapportés en interne décrivent, eux, une pression réelle pour produire davantage grâce à l'IA.
Dans cet article, on revient sur les faits rapportés, sur les risques d'une évaluation centrée sur l'usage des outils, et sur les garde-fous qu'une entreprise peut mettre en place pour intégrer l'IA sans dégrader la qualité, la sécurité ni la confiance.
Que prévoit Proton pour évaluer l'usage de l'IA ?
Selon une enquête de 404 Media, Proton prévoit des entretiens consacrés à l'usage de l'IA par certains salariés entre le 4 et le 11 novembre. Un courriel interne décrit ces échanges comme « conséquents » : les évaluations seraient ensuite communiquées à une revue plus large, susceptible de modifier les rôles et, potentiellement, d'influencer la poursuite de certains contrats de travail.
Le processus ne concernerait pas forcément toutes les équipes. Les entretiens seraient menés par des responsables extérieurs à l'équipe du salarié, choisis parmi des dirigeants jugés compétents sur les sujets d'IA. Andy Yen, directeur général, aurait commencé en interrogeant plus de quarante cadres en ingénierie et produits.
Une évaluation de l'adoption, mais aussi de l'emploi
Le point central, c'est la frontière entre « vérifier des compétences » et « décider qui reste ». Si l'entretien peut toucher au maintien dans l'emploi, on n'est plus dans une simple formation ni dans un partage de bonnes pratiques. Les salariés doivent alors savoir ce qui sera réellement évalué, selon quels critères, et s'ils disposent d'une possibilité de contester une appréciation.
Proton conteste l'idée d'utiliser l'IA comme prétexte à des licenciements. La société aurait déclaré sur Reddit, d'après TechRadar, ne pas procéder à des suppressions d'emplois et faire face à une pénurie de talents. Dans son récit, la démarche vise à comprendre où un accompagnement est nécessaire.
Mais ces explications ne font pas disparaître la tension. Le courriel cité par 404 Media évoque explicitement des conséquences possibles sur l'emploi, quand Proton insiste sur le fait qu'il ne s'agit pas d'un plan de licenciements. À ce stade, il faut donc distinguer ce qui est rapporté sur le processus, ce que l'entreprise dit, et ce qui n'est pas encore prouvé : les entretiens annoncés ne suffisent pas, à eux seuls, à conclure à des licenciements effectifs.
Un discours interne marqué par l'accélération
L'enquête de 404 Media s'appuie sur des salariés actuels et anciens, des échanges Slack, des enregistrements de réunions et un document attribué au directeur technique. Les éléments rapportés indiquent qu'en août, alors qu'un salarié demandait quelques jours pour tester la sécurité d'un nouveau code avant sa mise en production, Andy Yen aurait qualifié cette prudence de « pensée de perdant » et demandé aux équipes de cesser d'écrire le code à la main pour utiliser davantage l'IA.
Toujours selon les informations publiées, Andy Yen aurait aussi écrit : « Cette année sera la dernière où nous recruterons des ingénieurs. » Pris au pied de la lettre, ce type de phrase vise une rupture de rythme et de productivité. Elle ne prouve pas que Proton a stoppé le recrutement ni que tous les postes d'ingénierie vont disparaître. Mais elle éclaire le contexte d'entretiens où l'usage de l'IA pourrait peser sur la trajectoire professionnelle.
Pourquoi l'usage de l'IA ne suffit pas à mesurer la performance
À première vue, l'indicateur paraît simple : quelle part du code a été produite avec une IA ? D'après un propos attribué au directeur technique Bart Butler lors d'une réunion d'octobre, rapporté par 404 Media, l'IA aurait écrit 90 % du code de Proton. Des employés auraient aussi décrit un usage important de Claude, le modèle d'Anthropic. Enfin, l'entreprise aurait mis en place un logiciel qui suit la quantité de code générée par l'IA sur les ordinateurs professionnels.
Le problème, c'est que « produit avec une IA » peut donner l'illusion d'une mesure précise, sans dire grand-chose sur la qualité réelle. Le code est-il correct ? Maintenable ? Sûr ? Adapté au besoin ? Et surtout : combien de temps a été consacré à relire, tester, corriger et documenter le résultat ? Un outil peut générer beaucoup de texte, tout en laissant à l'ingénieur les décisions les plus difficiles.
L'activité visible n'est pas la valeur produite
Dans une équipe logicielle, le travail ne se résume pas à « écrire des lignes ». Comprendre un incident, poser les bonnes questions, choisir une architecture, repérer un défaut de sécurité ou refuser une fonctionnalité mal définie font partie des tâches les plus lourdes - et rarement visibles dans un simple compteur de production.
Ce risque est particulièrement fort dans une messagerie chiffrée. Un changement, même « petit » en apparence, peut impacter la confidentialité, la disponibilité ou la confiance. Dans ce contexte, le temps passé à vérifier une modification n'est pas forcément un retard : c'est souvent une partie du travail attendu.
Le même raisonnement vaut ailleurs. Pour un juriste, une réponse rédigée en quelques secondes n'est utile que si elle couvre bien la clause décisive. Pour une équipe en relation client, le nombre de réponses « assistées » par IA ne dit rien sur la justesse, ni sur la capacité à résoudre le vrai problème.
L'adoption forcée peut dégrader l'indicateur qu'elle cherche à améliorer
Quand une entreprise associe l'évaluation individuelle à l'usage d'un outil, les incitations changent vite. Les salariés ont intérêt à rendre l'usage visible - même quand l'IA apporte peu de valeur. Ils peuvent aussi réduire le temps passé à vérifier, pour afficher plus de production.
C'est un effet classique : dès qu'un chiffre devient une cible, les comportements finissent par s'adapter à la cible. Le résultat peut être une hausse de l'activité mesurée, sans hausse équivalente de la qualité. En ingénierie, cela peut se traduire par plus de code à relire, plus de défauts à corriger et une charge accrue pour la maintenance.
Cela dit, mesurer l'adoption peut avoir une utilité : vérifier si un outil est accessible, si les équipes sont formées, et quels usages émergent. Mais l'indicateur devient fragile dès qu'il sert seul à comparer des personnes ou à décider de leur place. L'usage de l'IA, au fond, reste une donnée de contexte : ce n'est pas une mesure complète de la performance.
Quels risques pour la qualité, la sécurité et les salariés ?
Le premier risque est opérationnel : accélérer la production sans adapter les contrôles. Selon 404 Media, un salarié de Proton aurait demandé plusieurs jours pour effectuer des tests de sécurité avant de livrer un nouveau code. La réaction rapportée d'Andy Yen pose une question simple : comment arbitre-t-on, concrètement, entre vitesse de mise en production et niveau de vérification ?
Il n'existe pas de délai de contrôle unique. Une modification cosmétique et un changement qui touche au chiffrement ne présentent pas le même niveau de risque. En revanche, demander d'aller plus vite sans préciser quels contrôles restent obligatoires déplace la pression vers les individus. Ceux-ci se retrouvent à arbitrer seuls entre le rythme attendu et les conséquences possibles d'une erreur.
La sécurité exige des contrôles proportionnés au risque
Dans des équipes qui manipulent des données sensibles, le code généré doit être traité comme du code à examiner - pas comme un résultat « fiable » par défaut. Cela implique de conserver des tests, des revues indépendantes et une procédure d'escalade lorsqu'un salarié estime qu'une livraison n'a pas été suffisamment vérifiée.
L'usage d'un modèle pose aussi des questions de confidentialité : quelles données vont à l'outil, dans quel environnement, avec quelles garanties ? Proton présente Lumo comme un assistant qui ne conserve pas les conversations et n'entraîne pas ses modèles sur les données des utilisateurs. Même si cela rassure, il reste nécessaire de définir des règles claires pour les outils utilisés en interne : quelles informations sont autorisées, et quelles configurations sont retenues.
La surveillance des outils change la relation de travail
Un logiciel qui mesure la part de code attribuée à l'IA peut aider à comprendre l'adoption. Il peut aussi être vécu comme un dispositif de surveillance, surtout si les salariés ne savent pas comment les données sont calculées, conservées, et éventuellement utilisées dans les décisions managériales.
En Europe, les outils de suivi des salariés doivent être examinés au regard du droit du travail, de la protection des données et des obligations d'information. Le RGPD impose notamment de justifier les traitements de données personnelles et de limiter la collecte à ce qui est nécessaire. Mais la conformité ne suffit pas toujours : une entreprise peut être « en règle » tout en installant un climat de défiance, si ses objectifs restent flous ou mal expliqués.
La confiance dépend aussi de la cohérence des messages. Le porte-parole de Proton aurait reconnu auprès de 404 Media que, dans l'objectif d'aller vite, l'entreprise avait parfois été trop abrupte ou pas assez claire en expliquant ses décisions aux équipes. Ce n'est pas une solution en soi au désaccord. Mais ça souligne un point souvent sous-estimé : une transformation technique se joue aussi dans la qualité de l'information donnée à ceux qui doivent la mettre en œuvre.
Comment une entreprise peut-elle adopter l'IA sans piège managérial ?
L'enjeu n'est pas de choisir entre adoption rapide et prudence absolue. Il faut plutôt définir où l'IA apporte un gain, quels contrôles ce gain impose, et comment l'entreprise reconnaît le travail humain qui reste indispensable. En clair : une politique utile part des tâches et des risques, pas d'un objectif abstrait d'usage généralisé.
-
Décrire les usages attendus, plutôt que fixer un quota
Dire « utilisez l'IA davantage » ne permet pas à une équipe de savoir quand l'outil est pertinent. Il vaut mieux préciser les usages autorisés et les situations où une vérification renforcée est requise. Pour le développement, ça peut couvrir la génération de tests, l'exploration d'une API ou la rédaction de documentation - tout en imposant une revue humaine avant fusion du code.
Le cadre doit aussi dire ce qui est interdit, ou soumis à validation : données client, secrets techniques, décisions automatisées sensibles, code qui touche à des composants critiques. Sans ça, chacun interprète « la limite acceptable » à sa manière.
-
Évaluer les résultats et les risques, pas le volume produit
Une évaluation équilibrée peut s'appuyer sur plusieurs indicateurs : délai de livraison, défauts découverts après mise en production, temps passé sur la maintenance, incidents de sécurité, et qualité perçue par les utilisateurs. Aucun chiffre ne suffit seul. L'intérêt vient de leur lecture ensemble, avec le contexte du projet.
Et si on compare avant/après l'introduction d'un assistant, il faut regarder aussi le coût de la relecture et des corrections. Une production plus rapide peut coûter plus cher si elle génère des erreurs ou de la dette technique. Le gain doit se mesurer sur le cycle complet, pas seulement au moment de la génération.
-
Séparer formation, accompagnement et sanction
Si l'objectif est d'identifier les besoins de soutien, l'entretien doit laisser place à une discussion sur les obstacles : manque de formation, outils mal adaptés, règles de sécurité floues, ou tâches où l'IA n'apporte pas grand-chose. Si l'entretien peut aussi impacter l'emploi, cette finalité doit être annoncée clairement, avec des critères partagés à l'avance.
Les responsables doivent aussi éviter de juger une personne sur un indicateur qu'elle ne contrôle pas entièrement. L'accès aux outils, la nature du poste, les contraintes de confidentialité et le niveau de risque varient selon les équipes. Une comparaison « au même moule » peut donc pénaliser ceux dont le travail demande plus de vérifications.
-
Garder une boucle de retour après le déploiement
Une politique IA ne s'arrête pas quand les licences sont distribuées ou quand la formation est terminée. Il faut recueillir les retours des équipes, suivre les incidents et ajuster les règles lorsque les outils ou les usages évoluent. Les services sécurité, RH, juridique et produit doivent faire partie de cette boucle.
Un signal utile est l'écart entre la production affichée et la qualité constatée : plus de code généré, mais aussi plus de corrections, plus de régressions, ou des retards en aval. Dans ce cas, la réponse n'est pas forcément de supprimer l'outil. L'idée est plutôt de comprendre à quelle étape le « gain apparent » se transforme en coût.
Conclusion : mesurer le travail, pas le volume d'IA
L'affaire Proton montre à quel point le débat sur l'IA en entreprise change de nature. La question n'est plus seulement de savoir si les salariés peuvent utiliser un assistant : c'est de savoir comment l'organisation définit la compétence, la productivité et le risque quand ces outils s'insèrent dans la production.
Les chiffres d'adoption peuvent aider à comprendre les usages. Ils deviennent problématiques quand ils remplacent l'évaluation du travail réel, ou quand ils servent de raccourci pour juger qui performe. Si une entreprise veut gagner en vitesse, elle doit aussi préserver le temps nécessaire à la vérification, rendre ses critères lisibles, et distinguer l'accompagnement d'une décision sur l'emploi.
Le bon test n'est donc pas « combien de code l'IA a-t-elle écrit ? », mais « quel résultat l'équipe livre, avec quel niveau de qualité, de sécurité et de responsabilité ? ». C'est à cette échelle que l'adoption de l'IA devient un sujet de produit et de management - pas juste un compteur à afficher.