L’annonce confuse
L’annonce d’emploi était parue en février sur l’un de ces tableaux où les entreprises italiennes de taille moyenne cherchent des profils techniques sans être trop sûres de ce qu’elles cherchent. L’intitulé du poste était “Senior Software Engineer with Regulatory Background”, et déjà là il y avait quelque chose d’étrange, parce qu’en italien une formule de ce genre ne signifie rien de précis. Le corps de l’annonce clarifiait peu. On demandait au moins cinq ans d’expérience en développement backend, de préférence Java ou Python, la connaissance de Kubernetes, l’expérience des pipelines CI/CD. Jusque-là, un profil de senior developer normal. Puis le texte changeait de registre et commençait à demander une connaissance approfondie du RGPD, la maîtrise de l’AI Act pour les systèmes à haut risque, la capacité à rédiger des AIPD et des évaluations de risque, l’expérience des frameworks de conformité comme ISO 27001 et SOC 2, la capacité à interfacer avec des auditeurs externes. La rémunération indiquée était celle d’un senior developer au prix du marché, avec un petit extra non quantifié pour les compétences réglementaires.
J’ai lu cette annonce une dizaine de fois en cherchant à comprendre qui ils cherchaient vraiment. Une personne pareille, avec cette combinaison de compétences, en Italie aujourd’hui, n’existe pas en nombres significatifs, et quand elle existe, elle coûte le double de ce que l’entreprise offrait. Que l’entreprise le sache ou non, c’est difficile à dire. Ce qui est certain, c’est qu’elle avait un besoin réel, parce qu’elle s’apprêtait à livrer un système à un client régulé, et qu’elle n’avait pas la bonne personne en interne. Elle avait des développeurs senior qui ne savaient pas lire un Règlement européen, un juriste interne qui ne savait pas lire le code, et un consultant compliance externe qui arrivait à parler avec l’un des deux mais pas avec l’autre. La personne qu’elle cherchait existait dans sa tête comme traducteur entre des mondes qui ne se parlaient pas, mais cette personne n’avait pas encore de nom de métier stable.
L’annonce a été republiée en mars sous un titre différent, “Compliance Engineer”, sans autre modification du corps. Puis elle a disparu. Je ne sais pas si l’entreprise a trouvé quelqu’un ou si elle a renoncé. Ce que je sais, c’est que des annonces comme celle-là, avec des variantes minimes, j’en vois passer une ou deux par semaine sur les tableaux italiens, et beaucoup plus sur ceux européens. Je vois un métier en train de chercher son nom, et qui le trouvera dans les deux ou trois prochaines années parce qu’il n’a pas d’alternative.
L’objection technologique
L’objection que je voudrais affronter tout de suite, parce qu’elle est la plus sérieuse de toutes et qu’elle est toujours posée par les C-level qui s’occupent des coûts, c’est l’objection technologique. Elle dit ceci : tout le travail que tu décris, l’IA le fera dans trois ans. Un agent lira le système, lira le règlement, produira la cartographie, mettra à jour la documentation, signalera les incohérences. Pas besoin de construire une nouvelle figure professionnelle, il suffit d’attendre que la technologie mûrisse. C’est une objection qui a une certaine plausibilité apparente, et elle est suffisamment répandue pour mériter une réponse. La réponse, c’est que l’IA fera vraiment quatre-vingt-dix pour cent du travail mécanique, et je ne fais pas ici des prévisions prudentes par excès, je décris ce qu’elle fait déjà aujourd’hui là où elle est appliquée sérieusement. Ce qui reste, les dix pour cent, ne correspondent pas aux dix pour cent résiduels qu’on suppose disparaître à mesure que les modèles s’améliorent. Ce sont les dix pour cent interprétatifs et politiques, et c’est exactement la part qui exige un être humain qui comprenne simultanément l’architecture du système et la structure du règlement, et qui sache choisir comment aligner les deux quand la lettre de la norme et la réalité du logiciel entrent en tension, ce qui arrive bien plus souvent que les régulateurs voudraient l’admettre.
En renversant la perspective, c’est en fait précisément l’IA qui rend la figure du compliance engineer économiquement viable. Sans assistance générative, le volume de documentation exigé par le nouveau régime européen serait ingérable pour quiconque n’est pas une multinationale avec une équipe dédiée de trente personnes. Une software house de dix ou quinze personnes ne peut pas se permettre deux personnes à plein temps sur cette fonction, et de fait aujourd’hui elle ne les a pas. Mais avec une assistance IA bien configurée, une seule personne, bien formée, peut superviser la compliance de tous les projets de l’entreprise avec une qualité qui aurait demandé une petite équipe il y a cinq ans. La question à se poser, donc, n’est pas si l’IA remplacera le compliance engineer, c’est exactement l’inverse. Sans IA, le compliance engineer n’existerait pas comme rôle accessible aux PME, il n’existerait que comme département des grandes entreprises. Avec l’IA, il devient la figure de synthèse qui permet aussi aux organisations de taille moyenne d’opérer sur des marchés régulés sans externaliser leur intelligence normative.
Une distance institutionnelle
La reconstruction des conditions qui ont fait émerger cette figure mérite quelques détails, parce que sa genèse est typiquement italienne et européenne, et comprendre la genèse aide à comprendre pourquoi le métier a la forme qu’il a. Le point de départ, c’est une distance institutionnelle entre deux traditions académiques et professionnelles qui en Italie, plus qu’ailleurs, ne se sont jamais sérieusement rencontrées. D’un côté, l’ingénierie informatique, formée dans les facultés d’ingénierie, avec une attention historique au fonctionnement du logiciel comme objet technique. De l’autre, le droit, formé dans les facultés de droit, avec une attention historique aux normes entendues comme textes à interpréter. Les deux traditions ne se parlent pas, non parce qu’il n’y aurait pas de personnes de bonne volonté qui essaient de bâtir des ponts, mais parce que les programmes de formation ne prévoient pas le pont comme objet d’étude structuré. L’ingénieur sort de l’université en sachant écrire du code et concevoir des systèmes, mais avec une exposition au droit qui se limite, dans les meilleurs cas, à un cours semestriel de droit de l’informatique souvent dispensé par un enseignant qui a étudié le logiciel comme phénomène et non comme pratique. Le juriste sort de l’université en sachant interpréter des normes, mais avec une exposition au logiciel qui se limite, dans les meilleurs cas, à quelques colloques et à quelques manuels de vulgarisation.
Cette distance n’était pas un problème sérieux tant que le logiciel était évalué sur la base de critères fonctionnels, de performance et commerciaux. Quand le logiciel a commencé à être évalué aussi sur des critères normatifs, le problème a explosé, parce que les organisations se sont retrouvées à devoir certifier au régulateur que leur système respectait des obligations que ni leurs développeurs ni leurs juristes ne savaient traduire complètement. Le RGPD, applicable depuis mai 2018, a été le premier test sérieux. Pendant des années, la réponse des entreprises italiennes a été d’externaliser la compliance à des consultants spécialisés, qui produisaient des documents adéquats mais entraient rarement dans le code, ou de nommer un Data Protection Officer interne ou fractionné qui parlait au juridique mais peu à l’ingénierie. Ça fonctionnait mal, mais ça fonctionnait suffisamment, parce que le RGPD seul n’était pas une pression suffisante pour faire émerger une nouvelle figure professionnelle.
La pression nécessaire est arrivée ces trois dernières années avec l’accumulation des actes du paquet réglementaire européen sur le numérique. AI Act, Cyber Resilience Act, révision de la Product Liability Directive, NIS2, Digital Operational Resilience Act pour le secteur financier, Data Act, European Accessibility Act. Chacun de ces règlements, pris individuellement, aurait été gérable avec les méthodes traditionnelles. Pris ensemble, et dans les délais comprimés où ils sont entrés ou sont en train d’entrer en vigueur entre 2024 et 2027, ils ont rendu la situation structurellement différente. Les organisations qui produisent du logiciel pour le marché européen se sont retrouvées avec des obligations documentaires, d’évaluation des risques, de sécurité, de traçabilité, d’accountability, qui se multiplient et s’entrecroisent de manière à exiger une vision intégrée. Le consultant externe qui produit un document à la fois ne suffit pas. Le juriste interne qui ne lit pas le code ne suffit pas. Le développeur senior qui explique le système aux auditeurs deux fois par an ne suffit pas, et la combinaison des trois figures mises à se coordonner par réunions périodiques ne suffit pas non plus, parce que la coordination par réunions périodiques est précisément le dispositif qui génère la dette de spécification. Il faut quelqu’un qui ne fasse que cela, et le fasse tous les jours, à l’intérieur de l’organisation.
Trois tranches dans une seule personne
Sur le plan de la taxonomie des figures professionnelles, ce qui se passe, c’est que le compliance engineer absorbe des tranches de travail aujourd’hui distribuées entre trois rôles distincts. Première tranche, le dev senior qui explique aujourd’hui le système aux auditeurs. C’est une figure qui existe dans presque toutes les organisations d’une certaine taille, et c’est presque toujours un senior qui connaît le système depuis des années et qu’on tire des projets de développement pour faire des présentations à des tiers. Il fait le travail à contrecœur parce que ce n’est pas pour cela qu’il a été embauché, il le fait avec une qualité médiocre parce qu’il n’a pas les outils documentaires pour bien le faire, et il occupe son temps avec des activités qui soustraient de la valeur au rôle principal. Deuxième tranche, l’architecte qui traduit aujourd’hui les exigences réglementaires en choix de design. Cette figure aussi est présente presque partout, et c’est généralement un architecte qui s’est auto-formé sur les règlements parce que quelqu’un devait le faire, et qui le fait dans le temps libre des décisions techniques, avec pour résultat que ses choix de design sont prudents par excès quand les règlements sont ambigus, et qu’il sur-régule souvent le système en générant des frictions opérationnelles inutiles. Troisième tranche, le juriste interne ou le consultant compliance qui essaie aujourd’hui de lire le code sans savoir le lire. C’est la figure la plus frustrée de toutes, parce qu’elle a la responsabilité formelle mais n’a pas les outils techniques pour l’exercer, et finit par demander aux dev des choses que les dev ne savent pas traduire en pratique, générant une boucle communicative qui produit des documents formellement corrects mais substantiellement inertes.
Une journée type
Le compliance engineer prend les trois tranches et les réunit dans une seule personne, avec un temps dédié et des outils dédiés. Une journée type, dans une entreprise moyenne qui produit du logiciel pour des clients régulés, commence par la revue des tickets de la semaine pour identifier les modifications de code qui impactent la compliance. Elle continue avec une session de travail sur une pull request spécifique pour discuter avec le reviewer architectural des effets d’une modification sur les flux de données personnelles. Elle se poursuit avec un appel au juriste interne pour clarifier une clause contractuelle que le client a proposée et qui pourrait entrer en tension avec notre annexe technique de sécurité. Après-midi de travail sur la mise à jour de l’AIPD du projet X, parce que le fournisseur tiers a changé de data center d’hébergement et que cela modifie la cartographie des flux transfrontières. Clôture par une réunion de sprint planning où le compliance engineer présente les exigences de documentation des trois prochaines tâches, pour que l’équipe sache ce qu’elle doit produire en plus du code. Rien de tout cela n’est juridique au sens strict, rien n’est technique au sens strict. Tout est techno-juridique, et c’est la nature hybride du travail qui justifie la figure.
Les deux dégénérescences
Le risque de la figure, et il faut le nommer explicitement parce que c’est le risque principal, c’est qu’elle puisse dégénérer dans deux directions pathologiques toutes deux déjà observables. La première dégénérescence, c’est le compliance engineer comme gate-keeper bureaucratique qui bloque les releases. C’est la version la plus visible et la plus dommageable, parce qu’elle oppose la veille compliance au delivery, et quand cette opposition se stabilise, l’organisation perd à la fois en vitesse et en qualité de compliance. Le gate-keeper produit des checklists toujours plus longues, exige des approbations toujours plus articulées, retarde les releases avec des motifs qui semblent à des développeurs des formalismes, et finit par être perçu comme un coût à minimiser plutôt que comme un investissement à préserver. La seconde dégénérescence, opposée dans les symptômes mais identique à la racine, c’est le compliance engineer comme décorateur de policy qui signe des documents sans lire le code. On voit cela davantage dans les entreprises où la figure est introduite parce qu’un client régulé ou un audit imminent l’exige, et où la fonction est confiée à une personne choisie pour sa disponibilité à supporter des charges documentaires plutôt que pour sa capacité réelle à lire le système. Le décorateur produit des documents parfaits du point de vue formel, remplit tous les champs requis, fait signer le management, et pendant ce temps le système réel évolue dans des directions que le document ne décrit plus. C’est exactement la condition que j’ai appelée dette de spécification dans le texte précédent de cette série, et que le compliance engineer devrait combattre mais qu’il contribue à générer s’il est mal interprété.
Les deux dégénérescences ont une cause commune, c’est l’absence de formation structurée de la figure. Quand le métier n’a pas de parcours académique de référence, chacun se le construit à partir de sa propre provenance. Le développeur qui devient compliance engineer apporte avec lui le préjugé que la compliance est une fonction de service du code, et tend à sous-estimer les conséquences juridiques des choix techniques. Le juriste qui devient compliance engineer apporte avec lui le préjugé inverse, que le code est une fonction de service de la norme, et tend à sur-réguler avec des conséquences techniques et organisationnelles lourdes. Une troisième trajectoire, de plus en plus fréquente, c’est celle du sysadmin qui devient compliance engineer par affinité naturelle avec les pratiques documentaires, et qui tend à construire des pipelines de certification qui vivent parallèles et jamais conjointes au cycle de développement applicatif. Il existe aussi une quatrième trajectoire, plus rare mais plus prometteuse, celle de ceux qui arrivent à la figure par des parcours mixtes, par exemple celles et ceux qui ont travaillé pendant des années en product management sur des produits régulés et ont développé une sensibilité aux deux côtés de la fracture. Aucune des trois premières trajectoires ne produit, à elle seule, un compliance engineer à la hauteur de la tâche. Elles produisent des demi-figures qui fonctionnent dans certaines entreprises et certains contextes, et qui échouent ailleurs.
Une vraie compétence bicéphale
Ce qu’il faudrait, et qui n’existe pas aujourd’hui, c’est un parcours formatif structuré qui parte de l’hypothèse que la discipline est génuinement bicéphale, ingénierique et juridique à la fois, et que les deux moitiés exigent solidité et non superficialité. L’ingénierie logicielle du compliance engineer se distingue de la version simplifiée et généraliste qu’on trouve dans les cours de vulgarisation, et exige de la vraie ingénierie logicielle, avec maîtrise des architectures distribuées, sécurité applicative, cycle de vie du code, pratiques DevOps, modélisation des données. La compliance du compliance engineer, de la même manière, va au-delà de la version opérationnelle et checklist-driven qu’on trouve dans les cours des business schools, et exige de la vraie jurisprudence européenne, avec maîtrise des Règlements, capacité de lecture des considérants, connaissance de la jurisprudence de la Cour de Justice, capacité d’anticiper l’évolution interprétative des Autorités nationales. Une personne qui possède tout cela ne se forme pas dans un master de six mois, elle se forme en quelques années de travail guidé par des mentors sérieux, et les mentors sérieux sont encore peu nombreux.
L’université italienne, de ce point de vue, est structurellement en retard. Les filières d’ingénierie informatique, même les meilleures, consacrent à la compliance réglementaire un nombre d’heures dérisoire par rapport au poids que cette discipline a pris sur le marché. Les filières de droit, même les meilleures, consacrent au logiciel en tant qu’objet régulé un nombre d’heures dérisoire par rapport à la centralité que le logiciel a dans l’économie. Il existe des masters post-universitaires qui essaient de combler le gap, et certains sont bien faits, mais ce sont des masters, c’est-à-dire des formations complémentaires de six ou douze mois qui ne construisent pas la double compétence à partir des fondations, mais la superposent à une compétence préexistante. Le résultat, c’est que les entreprises qui cherchent des compliance engineers ne les trouvent pas formés par le système universitaire et doivent les auto-former en interne, avec les délais et les coûts que cela implique. C’est une distorsion de marché classique, où la demande existe et l’offre ne s’est pas encore consolidée, et qui produit des postes vacants pendant des mois et des rémunérations volatiles.
Les grandes consultancy et le vide
Le segment de marché qui s’est en revanche déjà aperçu du phénomène, et qui se déplace pour l’occuper avant les autres, ce sont les grandes sociétés de conseil. C’est le phénomène le plus visible et le plus ambivalent, et il faut l’évaluer sans moralisme mais avec réalisme. Les grandes consultancy ont la force commerciale, la présence chez les clients corporate, des processus industriels pour le déploiement de figures professionnelles, et des budgets pour produire de la formation interne à des vitesses que les universités ne peuvent pas soutenir. Elles construisent des offres de “compliance as a service” qui empaquettent le travail du compliance engineer en lots vendables au poids. Le problème, et je le dis sans nommer aucun acteur spécifique parce que le problème est catégoriel et non individuel, c’est que la version de la figure que les grandes consultancy construisent est presque toujours la version décorateur de policy. C’est la plus scalable commercialement, la plus facile à vendre, la plus facile à industrialiser. Le compliance engineer comme vrai traducteur techno-juridique, celui qui entre dans le code et modifie les choix architecturaux, ne scale pas bien dans le modèle consulting, parce qu’il exige une continuité chez le client que le modèle par projets typique des grandes consultancy ne fournit pas facilement.
Le vide que les grandes consultancy ne réussiront pas à couvrir, et que les software houses italiennes pourraient en revanche couvrir, c’est celui du compliance engineer interne aux organisations qui produisent du logiciel pour des clients régulés. Les software houses de taille moyenne, entre dix et cinquante personnes, sont structurellement en meilleure position pour construire cette figure, à la fois face aux grandes consultancy et face aux entreprises régulées elles-mêmes. Elles ont la proximité technique au code que les consultancy n’ont pas, elles ont la pluralité de clients que les entreprises régulées n’ont pas, elles ont la taille qui permet de soutenir une personne dédiée sans devoir l’externaliser. Ce que beaucoup de software houses italiennes n’ont pas, et c’est la raison pour laquelle elles ne se déplacent pas assez vite, c’est la conscience que la transformation est déjà en cours et que celle qui la couvre la première obtiendra un avantage de position difficile à éroder dans les cinq années suivantes.
Sur le plan opérationnel, construire un compliance engineer interne signifie investir entre vingt-quatre et trente-six mois sur une personne qui a déjà la moitié des compétences nécessaires. Le candidat type est un développeur senior curieux de la dimension réglementaire, ou bien un architecte sensible aux thèmes de sécurité et de vie privée, ou encore une personne de product management ayant un certain goût pour la formalisation. La trajectoire de croissance prévoit du compagnonnage sur des cas réels, de la lecture systématique des règlements européens dans les versions linguistiques comparées, de la participation à des audits chez les clients, de la rédaction d’AIPD et d’évaluations de risque sous supervision, la construction de repositories documentaires, l’exposition progressive aux juristes internes et aux consultants externes pour absorber le vocabulaire et les pratiques juridiques par osmose. C’est un investissement significatif pour une petite software house, et c’est exactement le type d’investissement qui produit un actif compétitif difficilement reproductible.
Disclosure : une trajectoire que j’habite
Je dois être transparent, parce que sur ce sujet je décris un phénomène dont je fais partie, et l’analyse serait malhonnête si je ne le déclarais pas. La trajectoire que je décris, c’est celle que je vis personnellement dans mon entreprise, et une part non secondaire de mon travail des deux dernières années a consisté à construire le compliance engineer d’Oltrematica, en occupant directement cette position tout en cherchant à la formaliser pour qui viendra ensuite. Je n’écris pas ce texte comme observateur neutre d’une tendance qui serait celle des autres, je l’écris comme quelqu’un qui l’habite de l’intérieur et qui, après quelques années de pratique, a l’impression d’avoir compris la forme que la figure prend, et d’avoir quelque chose à dire sur ce qui fonctionne et ce qui ne fonctionne pas. Je ne suis particulièrement ni heureux ni fier de cette trajectoire. C’est simplement ce que le moment exige de qui veut continuer à faire du logiciel pour des clients régulés sans externaliser sa propre intelligence normative, et je l’ai accepté comme on accepte les tâches de transition, sachant que dans dix ans la figure sera évidente et qu’aujourd’hui c’est à nous de la construire à tâtons.
Connexion, et une prévision
Il y a un lien direct, et il vaut la peine de le rendre explicite, entre la figure que je décris et les deux essais précédents de cette série. Dans le texte que j’ai intitulé Cruft, pas patine, je soutenais que le logiciel ne sait pas vieillir, parce que la dérive entre le code et l’environnement dans lequel il tourne l’érode plus vite que la culture d’ingénierie n’arrive à le métaboliser. Dans le texte suivant, La dette de spécification, je soutenais que la spécification du logiciel vieillit encore plus mal que le code, parce que la pratique continue qui la maintiendrait en vie fait défaut, et que le cadre normatif européen charge ce vieillissement de conséquences juridiques jusque-là inexistantes. Le compliance engineer est la figure dont le métier consiste précisément à combattre la dette de spécification au quotidien, à maintenir la spécification alignée sur le système pendant que le système change, et à le faire avec la double compétence qui permet de ne tomber ni dans le formalisme du document ni dans l’inertie du code. C’est la personne qui, dans une organisation qui produit du logiciel, supervise l’alignement entre la promesse écrite et le comportement observé, sachant que sous le nouveau régime la cohérence entre les deux plans est ce que le juge évaluera si jamais arrive le jour de l’évaluation.
Le texte se ferme sur une prévision qui est aussi un appel à l’action pour qui me lit depuis l’intérieur d’une organisation qui fait du logiciel en Europe. Dans cinq ans, autour de 2031, la figure du compliance engineer sera évidente. Il y aura des filières universitaires, il y aura des certifications sérieuses, il y aura des ordres professionnels sous une forme ou une autre, il y aura des rubriques fixes dans la presse spécialisée. Ce qui reste à comprendre ne concerne pas si cela arrivera, mais seulement à quelle vitesse. Les organisations qui la construisent maintenant, de manière artisanale et par nécessité, auront un avantage structurel sur celles qui attendront la maturation du marché. L’avantage se joue au-delà du plan commercial, il est surtout cognitif, parce que celui qui habite le rôle aujourd’hui définit aussi les pratiques qui deviendront standard, et qui définit les pratiques les définit à la mesure de sa propre manière de travailler.
La figure du compliance engineer n’est pas une niche, c’est le rôle qui redessine la manière dont le logiciel européen est produit sous le nouveau régime réglementaire. Cela arrive lentement, en silence, dans des annonces confuses qui cherchent des personnes qui n’existent pas encore avec des titres qui changent d’un mois à l’autre. Quand les annonces trouveront leur nom stable, et cela arrivera bientôt, l’industrie se divisera entre celles qui auront investi sur cette figure à temps et celles qui se retrouveront à l’importer à marché consolidé en la payant trois fois plus cher. Qui me lit depuis l’intérieur d’une software house italienne de taille moyenne a probablement en entreprise, en ce moment, la bonne personne à former. C’est un dev senior avec la tête tournée vers les règlements, ou un architecte qui a commencé seul à lire le RGPD par curiosité, ou encore un sysadmin qui a pris à cœur la documentation parce que personne d’autre ne s’en occupait, et dans certains cas une figure plus hybride arrivée par des parcours mixtes qui n’entrent dans aucune des trois trajectoires classiques. La reconnaître et lui donner un mandat explicite, en y investissant du temps et une formation structurée, c’est la décision managériale qui produira le plus de valeur composée dans les cinq prochaines années. Pas parce que la figure est à la mode. Parce que sans elle, dans quelques années, faire du logiciel pour des clients régulés en Europe deviendra un métier que les software houses italiennes ne pourront plus se permettre.
Ce qu'il faut retenir
Le compliance engineer est la figure qui réunit dans une seule personne le travail aujourd’hui mal réparti entre le développeur senior qui explique le système aux auditeurs, l’architecte qui traduit les exigences réglementaires en choix de design, et le juriste interne qui essaie de lire le code sans savoir le lire.
L’IA ne remplacera pas le compliance engineer : elle est en train de rendre la figure économiquement accessible aux PME. Sans assistance générative, le volume documentaire exigé par le nouveau régime serait ingérable en dessous de trente personnes dédiées. Avec une IA bien configurée, une seule personne bien formée couvre toute la fonction.
Deux dégénérescences pathologiques sont déjà observables : le gate-keeper bureaucratique qui bloque les releases, et le décorateur de policy qui signe des documents sans lire le code. Toutes deux ont la même racine — l’absence de formation structurée — et produisent de la dette de spécification au lieu de la combattre.
L’université italienne accuse un retard structurel : ingénierie informatique consacre des heures dérisoires au droit, droit consacre des heures dérisoires au logiciel comme objet régulé. Les masters tentent de combler le gap, mais ils superposent à six ou douze mois une seconde compétence à une compétence préexistante au lieu de construire les deux depuis les fondations.
La fenêtre concurrentielle pour les software houses italiennes de taille moyenne est de deux à trois ans. Elles ont la proximité technique au code que les grandes consultancy n’ont pas, la pluralité de clients que les entreprises régulées n’ont pas, et la taille qui permet de soutenir une personne dédiée sans externaliser la fonction.
Questions & réponses
Qui est le « compliance engineer », et pourquoi en parle-t-on seulement maintenant ?
C’est la figure qui maintient en continu l’alignement entre ce que fait le code et ce que la documentation technique et réglementaire déclare. On en parle seulement maintenant parce que la pression qui la rend nécessaire est récente : l’accumulation des actes réglementaires européens sur le numérique entre 2024 et 2027 (AI Act, CRA, PLD révisée, NIS2, DORA, Data Act, EAA) a créé un volume d’obligations documentaires que le consultant externe ponctuel et le juriste interne déshabitué au code ne peuvent plus gérer seuls. La figure existait en germe dans les grandes entreprises ; le paquet réglementaire la promeut au rang de rôle structurel dans les organisations de taille moyenne aussi.
N'est-ce pas un métier que l'IA fera dans trois ans ?
Non, et l’observation est inversée par rapport à la manière dont on la formule habituellement. L’IA fera quatre-vingt-dix pour cent du travail mécanique — première rédaction d’AIPD, cartographie des flux, rédaction de SBOM, vérification de conformité aux considérants — et c’est déjà observable là où elle est appliquée sérieusement. Les dix pour cent restants ne sont pas le résiduel qui disparaîtra à mesure que les modèles s’améliorent, ce sont les dix pour cent interprétatifs et politiques qui exigent une personne capable de comprendre simultanément l’architecture du système et la structure du Règlement. C’est précisément l’IA qui rend la figure économiquement viable : sans elle, le compliance engineer n’existerait que comme un département de trente personnes en multinationale ; avec elle, une seule personne bien formée dans une software house de quinze couvre toute la fonction.
Comment le compliance engineer se distingue-t-il d'un DPO, d'un security architect ou d'un consultant compliance externe ?
Le DPO a des responsabilités formelles spécifiquement liées à la protection des données, définies par le RGPD, et c’est une figure juridiquement identifiée. Le security architect supervise l’architecture de sécurité du système. Le consultant externe produit des documents adéquats mais entre rarement dans le code. Le compliance engineer ne remplace pas ces trois figures, il les intègre : c’est la personne dédiée qui lit les pull requests avec l’œil du règlement, qui combat la dette de spécification, qui traduit du langage du code à celui du Règlement et inversement, et qui le fait tous les jours à l’intérieur de l’organisation, et non par projets.
Quelles sont les deux dégénérescences pathologiques à éviter dans la construction du rôle ?
La première est le gate-keeper bureaucratique, qui oppose la veille compliance au delivery et produit des checklists toujours plus longues, retardant les releases avec des motifs qui ressemblent à des formalismes pour les développeurs. La seconde est le décorateur de policy, qui signe des documents formellement parfaits sans lire le code, pendant que le système réel évolue dans des directions que le document ne décrit plus. Toutes deux partagent la même racine — l’absence de formation bicéphale — et elles produisent de la dette de spécification au lieu de la combattre. Le chemin étroit du vrai compliance engineer passe entre ces deux dérives.
Concrètement, comment une software house italienne de taille moyenne construit-elle cette figure ?
En investissant entre vingt-quatre et trente-six mois sur une personne qui possède déjà la moitié des compétences nécessaires : typiquement un développeur senior curieux de la dimension réglementaire, un architecte sensible à la sécurité et à la vie privée, ou une personne de product management ayant un certain goût pour la formalisation. Trajectoire de croissance : compagnonnage sur des cas réels, lecture systématique des Règlements européens dans les versions linguistiques comparées, participation à des audits chez les clients, rédaction d’AIPD sous supervision, exposition progressive au juriste interne pour absorber le vocabulaire par osmose. C’est un investissement significatif — et exactement le type d’investissement qui produit un actif compétitif difficilement reproductible.
Y a-t-il un lien entre le compliance engineer et les deux essais précédents (« Cruft, pas patine », « La dette de spécification ») ?
Oui, et c’est pour cela que j’ai écrit les trois textes en séquence. « Cruft, pas patine » soutenait que le logiciel ne sait pas vieillir, parce que la dérive entre le code et l’environnement l’érode. « La dette de spécification » soutenait que la spécification vieillit encore plus mal que le code, parce que la pratique continue qui la maintiendrait en vie fait défaut, et que le cadre normatif européen charge ce vieillissement de conséquences juridiques jusqu’ici inexistantes. Le compliance engineer est la figure dont le métier consiste précisément à combattre la dette de spécification au quotidien, à maintenir la spécification alignée sur le système pendant que le système change, et à le faire avec la double compétence qui permet de ne tomber ni dans le formalisme du document ni dans l’inertie du code.
L'auteur
