Open Source & Outils. IA et développement web : quel avenir pour l'open source ?

IA et développement web: quel avenir pour l’open source?

» La question revient désormais dans les entretiens avec une régularité presque gênante, chez des développeurs PHP en début de carrière comme chez des profils seniors qui ont déjà donné des soirées entières à une bibliothèque communautaire.

Ma réponse est directe: oui, contribuer reste utile. Mais non, la valeur d’une contribution ne se mesure plus au seul fait d’avoir soumis du code. Dans l’open source, l’intelligence artificielle accélère la production; elle ne distribue ni le discernement, ni la responsabilité, ni la confiance. Et c’est précisément là que se joue l’avenir de l’IA et du développement web open source.

Le marché du travail commence d’ailleurs à faire cette distinction. Produire vite une fonctionnalité est devenu plus accessible. Savoir si elle respecte l’architecture d’un projet, les contraintes de sécurité, les usages réels d’une communauté et la capacité d’une équipe de maintenance à l’assumer dans trois ans: voilà ce qui garde — et même augmente — sa valeur.

Drupal et WordPress ne bricolent plus l’IA dans leur coin

Pendant un temps, l’IA dans les CMS a surtout ressemblé à un catalogue d’extensions promettant de rédiger, traduire, résumer ou générer des blocs de contenu. Utile, parfois. Structurant, rarement. En 2026, les deux grands écosystèmes que sont Drupal et WordPress ont clairement changé de braquet: ils essaient de créer un socle commun plutôt que de laisser chaque extension inventer ses propres règles.

Côté Drupal, l’initiative Drupal AI, lancée officiellement en juin 2025 par cinq entreprises fondatrices — 1xINTERNET, Acquia, Dropsolid, FreelyGive et Salsa Digital — a réuni 34 partenaires et près de 14 000 installations en mai 2026. Ce n’est plus un projet annexe porté par quelques enthousiastes. L’initiative a aussi sécurisé 380 000 dollars en numéraire et 1,5 million de dollars de contributions en nature. Derrière les chiffres, il y a une réalité plus concrète pour les équipes PHP: l’IA entre dans les discussions d’architecture, de gouvernance éditoriale et de maintenance.

WordPress suit une trajectoire comparable, avec sa propre logique communautaire. Une équipe officielle dédiée à l’IA a été créée en mai 2025, puis l’initiative « AI Building Blocks for WordPress » a donné naissance à une extension canonique nommée « AI ». Sa version 1.0 est arrivée en mai 2026, suivie de la version 1.2.0 en juillet. L’enjeu n’est pas de transformer chaque site WordPress en démonstration technologique. Il est de fournir des briques réutilisables pour éviter que les développeurs et les éditeurs de solutions repartent de zéro à chaque intégration.

Cette nuance mérite d’être comprise, notamment en entretien.

L’IA ne devient pas intéressante parce qu’elle écrit du code ou des textes: elle le devient lorsqu’une équipe sait encadrer ce qu’elle lui délègue.

J’ai vu un candidat présenter un prototype capable de générer automatiquement des contenus dans un CMS. La démonstration était propre, rapide, convaincante à première vue. Puis le responsable technique lui a demandé: « Où sont stockées les consignes de marque? Qui valide une réponse inexacte? Et que se passe-t-il lorsqu’un contributeur modifie les règles? »

Silence. Pas parce que le candidat manquait de compétences, mais parce qu’il avait traité l’IA comme une fonctionnalité isolée. Or, dans un projet open source mature, une fonction sans gouvernance finit souvent par devenir une dette — technique, éditoriale et humaine.

Deux approches, une même exigence: rendre l’IA gouvernable

Drupal et WordPress ne proposent pas exactement la même expérience, mais ils répondent à une inquiétude commune: comment faire entrer l’IA dans un environnement ouvert sans laisser les équipes perdre la maîtrise de leurs données, de leurs règles et de leurs évolutions?

Pour un candidat, la leçon est simple: sur un poste PHP, annoncer que vous « savez utiliser l’IA » ne dit presque rien de votre adéquation. En revanche, pouvoir expliquer comment vous avez choisi un outil, défini ses limites, prévu une validation humaine et documenté son comportement, voilà qui raconte une posture professionnelle.

Les recruteurs techniques n’attendent pas que vous connaissiez par cœur chaque extension. Ils cherchent des personnes capables de distinguer une démonstration séduisante d’un outil réellement exploitable par une équipe.

La gouvernance devient une compétence, pas un supplément d’âme

Le mot gouvernance peut sembler un peu lourd pour parler d’un site web. Pourtant, c’est exactement le sujet. Quand une IA propose du contenu, résume une base documentaire ou assiste une équipe de développement, elle agit à partir d’un contexte. Si ce contexte est flou, contradictoire ou accessible à n’importe qui sans contrôle, le résultat sera à son image.

Drupal a mis ce point au centre avec Drupal AI Context, aussi appelé Context Control Center. Sa version Beta 2, publiée en mai 2026, permet de centraliser la voix de marque, les règles de gouvernance et les normes éditoriales pour les flux de travail IA. Dit autrement: on ne demande plus seulement à l’outil de « générer une réponse ». On lui indique depuis quel cadre il doit répondre, pour qui et avec quelles interdictions.

C’est une évolution majeure, y compris pour les métiers du développement web. Car la frontière entre le code, le contenu et l’organisation devient moins nette.

Dans une mission de recrutement récente, une entreprise cherchait un développeur PHP pour consolider plusieurs sites Drupal. La fiche de poste contenait au départ une ligne très vague: « participation aux projets IA ». Après discussion avec l’équipe, nous l’avons remplacée par des responsabilités plus honnêtes:

• intégrer des services IA sans contourner les règles de confidentialité du client;
• structurer des consignes réutilisables par les équipes éditoriales;
• prévoir un historique des usages et des validations;
• documenter les limites connues, au lieu de vendre une automatisation prétendument infaillible;
• travailler avec les métiers, car un bon résultat dépend autant de la qualité du contexte que de l’outil choisi.

Cette réécriture a attiré de meilleurs profils. Pourquoi? Parce qu’elle ne demandait pas un « magicien IA ». Elle nommait le vrai travail: rendre une technologie utilisable sans mettre l’équipe dans une situation intenable.

Ce que les recruteurs entendent derrière « expérience IA »

Soyons lucides: dans beaucoup d’annonces, « expérience de l’IA » reste une formule imprécise. C’est au candidat de la rendre concrète, sans en faire des tonnes. Voici les signaux qui comptent réellement dans un échange de recrutement:

1. Vous savez qualifier un besoin avant de choisir un outil.

Automatiser la création de fiches produit, assister la recherche dans une documentation interne et proposer du code sont trois sujets différents. Une personne solide ne répond pas avec le même dispositif à tout.

2. Vous parlez de contrôle humain sans jouer les rabat-joie.

Dire « il faudra valider » n’est pas une preuve de frilosité. C’est montrer que vous connaissez le coût d’une erreur publiée, d’une recommandation fausse ou d’une modification mal intégrée.

3. Vous comprenez la maintenance.

Une intégration IA n’est pas terminée le jour de sa mise en ligne. Les modèles changent, les coûts évoluent, les règles métier bougent, les contenus de référence vieillissent. Une solution sans propriétaire identifié finit très vite dans la pile des problèmes que personne ne veut reprendre.

4. Vous savez collaborer avec des non-techniciens.

Les soft skills ne sont pas là pour meubler une grille salariale. Elles font la différence lorsqu’il faut traduire une limite technique en décision compréhensible par une direction, une équipe éditoriale ou un client.

5. Vous pouvez dire ce que vous ne savez pas encore.

Cette capacité est sous-estimée. Face à l’IA, les promesses excessives coûtent cher. Une posture claire — « voici ce que j’ai testé, voici ce que je validerais avant déploiement » — inspire davantage confiance qu’un discours de certitude permanente.

Le vrai mur: les contributions rapides et la qualité lente

L’open source fonctionne sur une économie particulière: beaucoup de personnes peuvent proposer, très peu ont le temps de relire, tester, maintenir et arbitrer. L’IA accentue ce déséquilibre.

Une proposition de modification générée en quelques minutes peut sembler utile. Mais, pour le mainteneur, elle ouvre parfois une chaîne de travail beaucoup plus longue: comprendre l’intention, vérifier les dépendances, reproduire le problème, évaluer la sécurité, demander des corrections, expliquer un refus. La contribution est gratuite pour celui qui l’envoie; son traitement ne l’est jamais pour celui qui la reçoit.

GitHub a reconnu cette pression en juin 2026 en introduisant des limites persistantes et configurables sur les propositions de modification. L’idée n’est pas de bloquer automatiquement tout ce qui a été généré avec l’IA — ce serait absurde, et techniquement peu pertinent. Il s’agit de donner aux mainteneurs un levier pour réguler le volume lorsque le flux devient ingérable.

C’est un signal culturel fort. Pendant des années, contribuer a été présenté comme un geste naturellement positif: ouvrir une demande, proposer un correctif, enrichir un projet. Cela reste vrai, à condition de ne pas confondre abondance et aide.

Dans l’open source, une contribution utile n’est pas celle qui arrive vite; c’est celle qui réduit réellement le travail de la personne qui maintient le projet.

Un responsable de projet me racontait récemment son quotidien: « Je reçois des propositions très propres visuellement. Elles ont parfois un message détaillé, des fichiers modifiés, même des tests. Mais dès que je pose une question sur le choix effectué, il n’y a plus personne. Ou la réponse est une nouvelle explication générée, qui ne répond pas à la question. »

Cette phrase devrait rester dans la tête de tous ceux qui utilisent un assistant de code IA PHP. Le problème n’est pas d’avoir été aidé. Le problème est de soumettre un travail que l’on ne peut ni expliquer ni défendre.

Avant de proposer une modification, faites le travail que l’outil ne fera pas à votre place

Utiliser l’IA pour explorer une piste, préparer un test ou reformuler une documentation n’a rien de honteux. Prétendre qu’un résultat généré est votre compréhension du projet, en revanche, vous expose rapidement. Et dans une communauté technique, votre réputation se construit sur ce genre de détails.

Avant d’envoyer une proposition sur un projet open source PHP ou un CMS, prenez le temps de répondre à ces questions, avec vos mots:

• Quel problème précis cette modification résout-elle, et pour quels utilisateurs?
• Avez-vous lu les règles de contribution et les décisions déjà prises sur le sujet?
• Pouvez-vous expliquer chaque choix significatif sans renvoyer à « ce que l’outil a suggéré »?
• Qu’avez-vous testé dans un environnement proche de la réalité?
• Votre proposition ajoute-t-elle une charge de maintenance disproportionnée?
• Êtes-vous prêt à répondre aux retours, à corriger et, parfois, à accepter un refus?

Cela peut sembler exigeant. Ça l’est. Mais c’est aussi ce qui transforme une contribution en expérience professionnelle crédible. Sur un CV, « contribution open source » est une ligne banale. En entretien, raconter comment vous avez reçu un retour difficile, ajusté votre proposition et documenté votre décision montre une maturité que les entreprises cherchent activement.

Derrière chaque dépôt, il y a une personne qui tient la boutique

On parle beaucoup de productivité, beaucoup moins de fatigue. Or les chiffres disponibles sur les mainteneurs open source devraient calmer les enthousiasmes automatiques. Selon l’enquête Tidelift de 2024, 60 % des mainteneurs ne sont pas rémunérés pour leur travail; 58 % ont envisagé de démissionner, ou l’ont fait, en raison de l’épuisement professionnel.

Ce n’est pas un détail de contexte. C’est le cœur du problème.

Quand une entreprise s’appuie sur des composants libres pour livrer ses propres produits, elle bénéficie souvent du travail invisible de personnes qui répondent aux incidents, publient les correctifs de sécurité, tranchent les désaccords et absorbent les demandes mal préparées. L’IA peut soulager une partie de cette charge. Elle peut aussi l’aggraver brutalement si elle multiplie les sollicitations de faible qualité.

Il faut tenir les deux idées à la fois. Près de la moitié des mainteneurs utilisent eux-mêmes des outils de codage assistés par IA, avec une adoption particulièrement marquée chez les développeurs de moins de 26 ans. L’opposition n’est donc pas « humains contre IA ». La ligne de partage est plus saine: l’IA qui soutient un travail responsable contre l’IA qui déverse du travail non assumé sur les autres.

Pour les employeurs, cette réalité devrait changer le regard porté sur les contributions communautaires. Un développeur qui maintient une extension, répond à des signalements ou accompagne des nouveaux contributeurs développe des compétences rares:

• arbitrer avec des informations incomplètes;
• communiquer un refus sans casser une relation;
• prioriser dans un flux de demandes continu;
• tenir une ligne de qualité sous contrainte;
• rendre un choix technique compréhensible pour une communauté hétérogène.

Ce ne sont pas des activités périphériques. Ce sont des compétences de leadership, même lorsque le poste ne porte pas encore ce titre.

L’assistant IA peut renforcer un développeur PHP — à une condition

L’IA dans le développement web ne rend pas le développeur PHP obsolète. Elle rend plus visible l’écart entre une personne qui exécute une demande et une personne qui sait cadrer un problème.

Un assistant peut aider à lire une base de code ancienne, préparer une batterie de tests, retrouver une incohérence, proposer une première ébauche de documentation ou accélérer une tâche répétitive. Pour un profil junior, c’est un soutien réel. Pour un profil confirmé, c’est un accélérateur. Mais dans les deux cas, le résultat ne devient professionnel qu’après vérification.

La compatibilité annoncée autour de WordPress est révélatrice de cette tension entre innovation et réalité des parcs installés: l’extension officielle AI et le client PHP IA demandent au minimum PHP 7.4 et WordPress 7.0 ou supérieur pour fonctionner nativement. On peut trouver cela contraignant. C’est surtout un rappel: la modernisation ne se décide pas dans une présentation. Elle dépend des versions réellement déployées, des extensions existantes, des règles de sécurité et de la capacité d’une organisation à faire évoluer son environnement.

En recrutement, je conseille aux candidats de ne pas se positionner comme « experts IA » après deux essais sur un outil. La posture est fragile et les équipes sérieuses la repèrent vite. Mieux vaut dire:

— « J’utilise l’IA pour accélérer l’exploration et les tâches répétitives, mais je garde la responsabilité du résultat. »

Puis donner un exemple précis:

— « Sur ce projet, elle m’a aidé à préparer des scénarios de test. J’ai écarté certaines propositions car elles ne respectaient pas les conventions du dépôt, puis j’ai fait relire la modification avant de la soumettre. »

Cette réponse ne cherche pas à impressionner. Elle rassure. Et sur un marché où les entreprises cherchent à sécuriser leurs choix autant qu’à gagner du temps, c’est une valeur de négociation très concrète.

Votre avenir ne dépend pas d’un outil, mais de votre niveau d’exigence

L’IA va continuer à s’installer dans les projets Drupal, WordPress, les bibliothèques GitHub et les outils du quotidien. Les écosystèmes open source se structurent déjà pour l’accueillir; les mainteneurs se dotent de protections; les entreprises commencent à reformuler leurs besoins. Attendre que le mouvement se stabilise avant de vous y intéresser serait une mauvaise stratégie.

Mais courir après chaque nouveauté sans construire de méthode ne vous donnera pas davantage de valeur sur le marché.

Votre plan d’action peut rester très simple: choisissez un projet que vous utilisez réellement, observez comment sa communauté accueille les contributions, utilisez un outil IA sur une tâche limitée, vérifiez le résultat ligne par ligne, puis documentez ce que vous avez appris — y compris ce qui n’a pas fonctionné. Ensuite, parlez-en avec précision lors de vos entretiens.

L’open source n’a pas besoin de davantage de code envoyé à toute vitesse. Il a besoin de professionnels capables d’apporter de la clarté, de la continuité et du respect pour le temps des autres. C’est moins spectaculaire qu’une promesse d’automatisation totale. C’est aussi, franchement, beaucoup plus précieux.