La discussion se déroule presque toujours de la même façon. Une équipe de développement demande un assistant de codage. La sécurité demande où s’en va le code source. Personne n’a de réponse ferme. La demande s’enlise.
Six mois plus tard, l’outil est utilisé de toute façon — sur des comptes personnels, hors de l’authentification unique, sans journalisation et sans politique.
Le refus n’a pas empêché l’adoption. Il a empêché la visibilité sur l’adoption.
C’est le vrai choix devant vous. Pas de savoir si vos développeurs utiliseront ces outils, mais de savoir si la version qu’ils utilisent est celle que vous avez configurée.
Le risque n’est pas celui que vous discutez en comité
L’objection est presque toujours formulée comme une question de modèle : où s’en va notre code, et sert-il à l’entraînement ? C’est une vraie question, les fournisseurs y répondent dans leurs offres entreprise, et elle se règle en un après-midi. Une fois réglée, l’approbation ne vient toujours pas — parce que le modèle n’a jamais été la partie risquée.
Deux risques comptent davantage, et aucun des deux ne concerne le fournisseur.
Le premier : l’assistant hérite de tous les droits du développeur qui l’utilise. Il voit les dépôts que cette personne voit. Il lit les fichiers qu’elle peut lire. S’il est branché au système de billets ou à la documentation interne, il y accède aussi. Vous n’ajoutez pas un modèle à votre parc : vous ajoutez un acteur très rapide, très littéral, doté des accès d’un humain et d’aucune de ses hésitations.
Le second, plus insidieux : le code plausible. La défaillance la plus fréquente en pratique n’est pas une fuite, c’est du code confidemment faux qui passe la revue parce qu’il a l’air correct. Un développeur qui relit le code d’un collègue sait quoi chercher : les raccourcis habituels de cette personne, ses angles morts. Devant une production générée, ces repères n’existent pas. La revue devient une lecture de plausibilité — et la plausibilité est exactement ce que l’outil optimise.
Cadré ainsi, le dossier cesse d’être une question d’approvisionnement et devient une question d’accès et de preuve. C’est un problème que votre organisation sait déjà traiter.
Quatre choses à régler avant le déploiement général
1. Décider qui y a droit, délibérément
Le déploiement par défaut, c’est « tout le monde qui a une licence ». Ce n’est pas une décision, c’est l’absence de décision. Cadrez les habilitations comme pour tout système qui atteint du code source : quelles équipes, quels dépôts, quels environnements.
La conversation utile n’est pas qui en veut, mais quels accès serions-nous mal à l’aise de voir amplifiés. Un consultant externe disposant d’un accès en lecture large sur plusieurs dépôts n’est pas la même proposition qu’un ingénieur permanent affecté à un seul produit. Même outil, exposition différente.
Cas particulier fréquent au Québec : si vous êtes vous-même fournisseur et que vos développeurs travaillent sur du code appartenant à vos clients, vérifiez ce que disent vos contrats avant d’activer l’outil. Une clause de confidentialité rédigée avant l’existence de ces outils ne les mentionne pas — ce qui ne signifie pas qu’elle les permet.
2. Écrire une politique d’usage réellement applicable
La plupart des politiques d’usage de l’IA sont des documents d’intention qui disent « faites preuve de jugement » et ne sont plus jamais consultés. Une politique ne vaut d’être écrite que si une personne précise peut pointer une ligne précise quand quelque chose tourne mal.
Une politique utilisable est courte et concrète : quelles catégories de données ne doivent jamais être collées dans une invite, quel code exige une revue humaine avant fusion quel qu’en soit l’auteur, et ce qui se passe quand l’assistant produit quelque chose que le développeur ne comprend pas.
Ce dernier point compte plus qu’il n’y paraît. C’est la seule règle qui traite directement du risque de code plausible, et c’est celle que les politiques omettent systématiquement.
3. Durcir la configuration au-delà des valeurs par défaut
Les offres entreprise sont livrées avec des réglages qui favorisent l’adoption plutôt que le contrôle. Passez-les en revue explicitement au lieu d’accepter l’état livré : quels dépôts sont indexés, si les suggestions issues de code public sont permises, quelle télémétrie sort du locataire, comment l’outil s’authentifie.
C’est ingrat, et c’est là que se trouve l’essentiel de la réduction de risque réelle. C’est aussi l’étape la plus souvent sautée, parce qu’elle ne produit rien à montrer à un comité directeur.
4. Journaliser comme un système de production
Si vous ne pouvez pas répondre dans six mois à qui l’a utilisé, quand, et sur quoi, vous n’avez pas déployé un outil encadré : vous avez déployé un outil non surveillé accompagné d’un bon de commande.
La journalisation est ce qui transforme les trois autres contrôles d’affirmations en éléments de preuve. C’est aussi ce qui vous permet de clore le débat : à la prochaine question — « est-ce que ça sert vraiment ? » — vous répondez avec des données plutôt qu’avec une opinion.
Ce qu’il faut changer dans la revue de code
C’est la partie que la plupart des organisations omettent, parce qu’elle ne relève pas de la sécurité au sens strict.
Si une part croissante du code fusionné n’a pas été écrite par la personne qui le soumet, votre processus de revue repose sur une hypothèse qui n’est plus vraie. Trois ajustements, par ordre de rendement :
- Exiger que le soumettant puisse expliquer le code. Pas une politique formelle : une norme d’équipe. « Je ne sais pas, c’est ce que l’outil a produit » doit être une réponse inacceptable en revue.
- Concentrer la revue humaine sur les frontières. Les erreurs générées les plus coûteuses se situent aux interfaces — validation d’entrées, décisions d’autorisation, gestion d’erreurs — pas dans la logique métier, où elles sont visibles.
- Mesurer avant d’argumenter. Si vous soupçonnez une dégradation de la qualité, comparez les taux de défauts avant et après plutôt que de débattre d’impressions. Sans mesure, la discussion se règle au plus convaincu.
Le vrai test arrive ensuite
Les assistants de codage sont le cas facile. Le cas difficile arrive quand le même fournisseur livre un outil permettant à des non-développeurs de construire leurs propres agents.
La question de sécurité cesse alors de porter sur un produit et porte sur des centaines de petits produits, construits par des personnes qui ne se considèrent pas comme des développeurs et qui ne viendront pas vous demander de revue. Le traitement des données, l’authentification et la journalisation doivent être réglés sur la plateforme, avant la disponibilité générale — parce que rattraper la gouvernance sur des agents déjà existants revient à auditer un travail dont vous ignoriez l’existence.
Si votre organisation approche de l’activation de ce type d’outil, faites ce travail préalable maintenant. Ce sont les mêmes quatre contrôles, appliqués un étage plus haut, et ils coûtent infiniment moins cher avant le lancement qu’après.
Par où commencer
Si une demande est sur votre bureau en ce moment, dans cet ordre :
- Demandez de quels accès l’assistant hérite, pas ce que le fournisseur fait des données.
- Cadrez les habilitations avant de négocier le nombre de licences.
- Parcourez les réglages entreprise et notez chaque valeur par défaut modifiée, et pourquoi.
- Activez la journalisation avant le premier utilisateur, pas après le premier incident.
Rien de tout cela n’exige un nouvel outil, une nouvelle enveloppe budgétaire ou un projet de recherche. Il s’agit de traiter un assistant de codage pour ce qu’il est : une nouvelle identité disposant des accès de vos développeurs — une catégorie que votre organisation encadre depuis des années.
Besoin d’aide pour mettre cela en œuvre ?
Nous travaillons avec votre équipe pour concevoir, construire et exploiter les contrôles décrits ci-dessus.