Vos développeurs citoyens créent leurs outils avec l’IA, dans un cadre que vous fixez

Qu’est-ce qu’un développeur citoyen en entreprise ?

Un développeur citoyen est un salarié, souvent à la RH, aux achats, à la finance ou dans les opérations, qui crée lui-même les outils dont son équipe a besoin : un suivi de demandes, un planning, un registre. Il n’a pas fait d’études d’informatique et ce n’est pas son métier. Il connaît en revanche les règles de son service mieux que quiconque.

Dans son glossaire, le cabinet Gartner définit le « citizen developer » comme un salarié qui crée des applications pour lui-même ou pour d’autres, avec des outils que l’informatique ou les métiers n’ont pas interdits, et qui dépend d’un service autre que la DSI. Cette définition compte donc aussi les outils faits en marge. Pour la DSI, la question n’est pas de savoir s’il y a des développeurs citoyens dans l’entreprise, mais s’ils sont encadrés.

Comment mettre en place un programme de développeurs citoyens ?

Un programme tient en quatre décisions. Qui peut créer : des volontaires, choisis avec leur responsable, avec du temps dégagé. Qui peut publier : seuls les outils qui passent une revue sont ouverts aux collègues. Quelles informations : on définit ce qui peut entrer dans un outil créé par un métier et ce qui reste réservé aux équipes informatiques, par exemple les données de paie ou de santé. Un outil de congés ou de formations traite des données personnelles : il entre au registre des traitements prévu par l’article 30 du RGPD et le référent prévient le DPO. Quel soutien : une personne référente répond aux questions et relit les premiers outils.

Démarrez petit : trois à cinq volontaires, deux équipes, trois outils simples. Prévoyez une revue mensuelle où chaque Propriétaire présente son outil en cinq minutes. Ce rendez-vous sert à repérer les doublons, à choisir quels outils méritent d’être consolidés et à faire circuler les bonnes idées. Le programme réussit quand les volontaires y gagnent aussi : de la visibilité, du temps réservé, une reconnaissance dans leur évaluation.

Quels outils pour un développeur citoyen : low-code, no-code ou IA ?

Les plateformes low-code offrent beaucoup de puissance, mais elles demandent une vraie formation et attirent surtout des profils techniques. Les outils no-code sont plus simples, mais chaque plateforme a sa logique à apprendre et un collaborateur qui n’en fait qu’une fois par trimestre oublie vite.

Avec l’IA, la personne décrit l’outil dans un prompt, comme elle l’expliquerait à un collègue, puis demande des changements en français. Pas de plateforme à apprendre, seulement à bien expliquer son besoin, mais deux risques à encadrer : la qualité de ce que l’IA écrit et l’endroit où l’outil est mis en ligne. D’où l’intérêt d’une vérification systématique avant chaque publication.

Les développeurs citoyens posent-ils un problème de sécurité ?

Le risque principal n’est pas l’outil créé, c’est l’outil créé hors de tout cadre : un fichier partagé par un lien public, un mot de passe commun, une application hébergée sur un compte personnel. Un programme encadré réduit ce risque, parce qu’il offre un chemin officiel plus simple que le contournement.

Quatre contrôles suffisent pour commencer. Un registre des outils, avec un Propriétaire pour chacun. Des droits d’accès par personne, jamais un mot de passe partagé. Une vérification avant chaque mise en ligne. Et une règle claire sur les informations interdites. Le RSSI valide ce cadre une fois, puis les équipes l’appliquent.