Pourquoi Skai des règles : comment l'adoption d'une approche « agentique » a permis d'augmenter de 500 % la productivité de l'équipe de développement

Une entreprise qui propose un produit basé sur l'IA de nouvelle génération doit être une entreprise qui donne la priorité à cette technologie. On ne peut pas continuer à fonctionner à l'ancienne tout en proposant de l'IA de nouvelle génération, car on perd alors le contact avec ce que vivent ses développeurs. C'est cette conviction qui a été à l'origine de la transformation Skai, et les résultats sont incontestables.

Les outils d’IA générique faisaient déjà partie intégrante de nos méthodes de travail, et depuis des années, ils donnaient des résultats concrets : une amélioration du rendement comprise entre 7 % et 12 %. Des chiffres significatifs, mais pas de ceux qui transforment une entreprise. Au début de l’année 2025, j’ai rencontré Ofir Ben Dor, notre directeur de l’ingénierie chez Skai, et nous avons commencé à nous poser une question différente : que faudrait-il réellement pour multiplier ce rendement par 10 ?

La plupart des organisations tirent parti de l'IA générative au niveau des tâches, en optimisant les résultats individuels tout en laissant pratiquement intact le système dans lequel ces résultats s'inscrivent. Les équipes qui prennent une longueur d'avance sont celles qui osent remettre en question le système lui-même.

L'expérience

Plutôt que de débattre de la théorie, nous avons mené une expérience aux enjeux réels.

Nous avons choisi une fonctionnalité complexe qui aurait normalement nécessité une équipe composée de cinq développeurs, d’un chef de produit et d’un concepteur UX travaillant ensemble pendant environ six mois. Nous avons constitué une équipe plus réduite : trois développeurs, un chef de produit et un concepteur UX. Nous leur avons ensuite demandé de mettre de côté tout ce qu’ils savaient sur la manière dont les logiciels sont développés.

Oublions les processus, le cycle de vie structuré du développement logiciel, les hypothèses du modèle « en cascade » et les méthodologies agiles que nous avions mis des années à perfectionner. Partons des principes fondamentaux, travaillons comme une seule et même équipe, et livrons nos produits en quelques semaines plutôt qu’en plusieurs mois. La seule contrainte non négociable : la qualité. Nos clients nous confient leur activité, et cette confiance est au cœur de tout ce que nous faisons.

Trois semaines plus tard, la fonctionnalité était terminée. Six mois de travail prévus, réalisés en trois semaines, par la moitié de l'équipe.

Lorsque nous leur avons demandé ce qui avait fait la différence, l’équipe a identifié plusieurs facteurs. Les cloisonnements entre les équipes produit, UX et développement avaient disparu : elles fonctionnaient comme une seule et même entité, dotée d’un pouvoir décisionnel total et sans avoir à attendre l’aval de la hiérarchie. Toutes les pertes de temps inhérentes au processus traditionnel – les validations, les files d’attente, les transferts de tâches – avaient été éliminées. L’équipe n’avait qu’une seule mission : développer. Il n’y avait pas de priorités concurrentes, ni d’interruptions dues à des tickets d’assistance ou à des files d’attente de bogues. Et leur recours à Claude était passé d’un rôle complémentaire à un rôle fondamental.

Une expérience ne constitue qu'un point de données, mais il nous en fallait davantage. Nous avons lancé cinq projets supplémentaires dans les mêmes conditions : pas de compromis sur la qualité, optimisation du calendrier, travail en autonomie. Les résultats ont été cohérents. Lorsque nous avons atteint le nombre de quinze projets sur un trimestre complet, la conclusion s'est imposée d'elle-même. Il ne s'agissait pas d'un cas isolé. C'était notre nouveau modèle.

Refonte du modèle opérationnel

Pour reproduire ces résultats à grande échelle, il ne suffisait pas d'un simple changement d'attitude. Il fallait un changement structurel. L'initiative reposait sur les piliers suivants :

La première consistait à réécrire entièrement le mode de fonctionnement. 

Le cycle de vie traditionnel du développement logiciel (analyse du marché, élaboration du cahier des charges, spécifications fonctionnelles, conception, développement, assurance qualité) a été conçu autour de transferts de tâches entre personnes à chaque étape. Dans un monde où les agents peuvent intervenir simultanément à plusieurs étapes, cette architecture devient un goulot d'étranglement. Nous avons donc repensé la nôtre de A à Z.

La deuxième mesure a consisté à réorganiser les équipes de développement en « pods ».

Cela comprenait de petites unités interfonctionnelles dotées d’un réel pouvoir de décision et ne nécessitant aucune escalade. Nous avons supprimé un niveau hiérarchique et remplacé les chefs d’équipe par une structure plus horizontale d’équipes d’ingénierie, chacune s’appuyant sur des « pods » de fonctionnalités intégrés et un « pod » de production dédié. Ce « pod » de production a une raison d’être bien précise : absorber tous les tickets entrants et les problèmes des clients afin que les « pods » de fonctionnalités puissent rester concentrés sur leur travail sans avoir à changer constamment de contexte.

C'est le troisième pilier que je considère comme le plus déterminant. 

L'efficacité des agents dépend entièrement du contexte dans lequel ils évoluent, et nous avons pris conscience que nous n'avions jamais véritablement documenté ce que nous avions mis en place. Pour la première fois dans l'histoire Skai, nous avons cartographié systématiquement l'ensemble de notre système. Nous l'avons baptisé « Product Atlas ». Cela a apporté à nos agents quelque chose dont ils n'avaient jamais disposé auparavant : une vision complète et fiable de l'environnement dans lequel ils travaillaient.

Huit jours

La page d'accueil de Gen AI a été le premier projet livré dans le cadre de ce nouveau modèle, mais ce n'était pas la seule preuve de son efficacité. Lorsqu'une plateforme d'IA de premier plan nous a contactés pour que nous prenions en charge de nouveaux formats publicitaires, nous sommes passés de la première discussion à la mise en place effective en huit jours. 

Ce même projet aurait nécessité un trimestre entier avec une équipe au complet selon notre ancien modèle. Quinze autres projets ont suivi, tous illustrant la même situation.

De 7 % à 5 fois

Avant tout cela, les gains de productivité générés par l'IA générative oscillaient entre 7 et 12 %. Aujourd'hui, nous en sommes à 5 fois ce niveau, et l'objectif est d'atteindre 10 fois ce niveau : passer de 7 % à 500 %, avec un objectif de 1 000 %.

Ce qui me revient sans cesse à l'esprit, ce n'est pas seulement la rapidité. Dans toute entreprise technologique, la capacité de développement a toujours constitué le frein principal, et on ne pouvait aller plus vite que ne le permettait son équipe de développement. 

Aujourd’hui, je peux vous affirmer que nous sommes une organisation complètement différente, et que le principal frein n’est plus le développement. Éliminer les cloisonnements, réduire les goulots d’étranglement liés aux validations, préserver la concentration des équipes : ces changements nous ont permis de raccourcir les délais sans compromettre la qualité. Les éléments qui nous ralentissaient depuis toujours n’étaient pas une fatalité. Il s’agissait de problèmes de conception, et nous les avons résolus en repensant notre organisation.

Plus grand que le cloud

Je travaille dans ce secteur depuis plus de 30 ans. Le changement le plus radical que j’avais connu auparavant était le passage des logiciels sur site au cloud. L’intégration continue a également bouleversé la manière dont les équipes déploient et assurent la maintenance des logiciels. 

C'était déjà significatif, mais le passage au cloud n'a pas permis d'obtenir une amélioration multipliée par 10. Peut-être par 2, ce qui est déjà considérable : cela équivaut à doubler vos effectifs d'ingénieurs du jour au lendemain. Ce que nous faisons actuellement relève d'un tout autre ordre de grandeur. Il s'agit d'une amélioration bien plus importante, d'un facteur et non d'une simple marge.

Et maintenant ?

La phase suivante consiste en une orchestration complète : les agents fonctionnent comme de véritables membres d’un « pod », prennent en charge les tickets de bogues, déploient les correctifs en production, décomposent les cahiers des charges en épopées et en stories, et mènent les tâches de leur lancement à leur achèvement. L’objectif est de mettre en place un modèle dans lequel des agents autonomes travaillent en parallèle sur autant de flux de travail que nécessaire. Les humains définissent la direction à suivre, vérifient les résultats, puis passent à autre chose. Les agents se chargent de l’exécution.

C'est la clé pour multiplier par 10 la capacité : multiplier le nombre de projets qu'une équipe de développement peut mener de front, grâce à des agents chargés de l'exécution.

C'est cette même philosophie qui est à l'origine de Skai , que nous avons présenté en avant-première lors du ShopAble 2026 : un environnement entièrement basé sur des agents, dans lequel les équipes marketing créent et coordonnent une main-d'œuvre alimentée par l'IA, composée d'agents spécialisés qui mènent des campagnes, optimisent les budgets et mettent en évidence des informations pertinentes sans aucune intervention manuelle. Nous n'aurions pas pu le développer de manière crédible sans avoir d'abord appris nous-mêmes ce que signifie travailler de cette façon.

Une entreprise qui propose un produit basé sur l'IA de nouvelle génération doit être une entreprise qui donne la priorité à cette technologie. Sa transformation interne en est la preuve de concept, et les questions sur lesquelles nous nous sommes penchés (où l'agent intervient-il, où l'humain prend-il la décision ?) sont celles auxquelles toutes les équipes produit, marketing et opérations seront bientôt confrontées.

Vous êtes déjà Skai ? Contactez votre équipe d'accompagnement pour commencer à utiliser Custom Agents. Vous découvrez Skai? Prenez rendez-vous pour une démonstration.

---

Questions fréquemment posées