Nous construisons désormais en trois mois ce qui nous prenait trois ans. C'est là que commence le plus difficile.

Quelque chose a changé dans notre équipe de développement cette année, et je m’y habitue encore. Au cours des trois derniers mois, une poignée de personnes chez Guardian360 ont reconstruit notre plateforme Lighthouse et l’ont enrichie de plus de nouvelles fonctionnalités que nous n’en livrions autrefois en plus de trois ans. Nous n’avons pas recruté une équipe plus large et nous n’avons pas trouvé un budget plus important. Le développement logiciel assisté par l’IA a simplement levé la contrainte qui façonnait chacune des décisions de notre feuille de route : la pénurie de personnes et d’outils.

Cela ressemble à une bonne nouvelle, et c’en est largement une. Mais cela a révélé une nouvelle contrainte, et elle ne se trouve pas là où je m’attendais à la trouver. Lorsque construire n’est plus rare, c’est la mise en œuvre qui le devient. Nos partenaires, les managed service providers (MSPs) qui livrent notre plateforme de cybersécurité à leurs clients, ne peuvent pas absorber de nouvelles fonctionnalités au rythme auquel nous sommes désormais capables de les produire. Et deux autres questions m’occupent l’esprit. Un logiciel construit aussi vite est-il réellement sûr ? Et davantage de fonctionnalités pourraient-elles éroder la simplicité qui nous a toujours distingués ?

Qu’est-ce qui change lorsque construire n’est plus le goulot d’étranglement ?

Pendant la majeure partie de l’histoire de Guardian360, notre feuille de route était une liste de choses que nous voulions construire, classées selon ce que nous pouvions nous permettre de construire. Des partenaires réclamaient certaines fonctionnalités depuis des années, et beaucoup d’entre eux ont dû attendre.

Aujourd’hui, nos développeurs travaillent aux côtés de l’IA pour la génération de code, les tests et la documentation. Nous avons commencé avec Claude, le modèle d’Anthropic, et nous déplaçons de plus en plus ce travail vers Hermes. Hermes n’est pas un modèle mais une couche que nous avons construite nous-mêmes. Elle utilise des grands modèles de langage open source pour alimenter ce que nous appelons un cerveau d’entreprise, et elle facilite le travail des agents IA qui nous aident sur une large gamme de tâches. Hermes, et les modèles open source qu’il utilise, tournent dans notre propre cluster de serveurs aux Pays-Bas, et c’est autant une question de principe que de pragmatisme. Claude n’a jamais eu accès aux données clients de notre plateforme, car nos accords de partenariat ne permettent pas à ces données de quitter l’EU. Déplacer une plus grande part de notre travail vers une infrastructure que nous contrôlons suit la même logique.

Nous sommes loin d’être une exception. Selon le 2026 GenAI Code Security Report de Veracode, l’IA génère désormais environ la moitié de tout le code commité. La question n’est plus de savoir si les équipes logicielles utilisent l’IA, mais ce qui se passe ensuite.

Un logiciel construit avec l’IA est-il réellement sûr ?

C’est la préoccupation que je prends le plus au sérieux, et je soupçonne que c’est la première question que beaucoup de lecteurs se poseront. La recherche donne peu de raisons de se rassurer. Veracode a constaté qu’environ 44 pour cent des tâches de génération de code par IA introduisaient une vulnérabilité à risque, avec un taux moyen de réussite en matière de sécurité de 56 pour cent, à peine différent des 55 pour cent de son premier rapport. L’étude d’avril 2026 d’IOActive a analysé près de 20 000 échantillons de code et a constaté que 31,6 pour cent des échantillons générés par IA étaient entièrement exploitables ; aucun modèle n’a produit une sortie entièrement sûre.

Ce qui m’inquiète encore davantage, c’est l’écart entre la perception et la réalité. La Cloud Security Alliance rapporte que plus de 75 pour cent des développeurs interrogés dans une enquête estimaient que le code généré par IA est plus sûr que le code écrit par un humain, tandis que 56 pour cent reconnaissaient qu’il introduit fréquemment des problèmes de sécurité. La rapidité donne l’impression de la compétence. Elle ne l’est pas.

La conclusion d’IOActive est que les organisations doivent traiter la sortie de l’IA comme une entrée non fiable et imposer une revue de sécurité obligatoire avant tout déploiement. C’est exactement ainsi que nous travaillons : l’IA peut écrire le code, mais chaque modification est revue par une personne qui la comprend avant qu’elle n’atteigne la production. Nous allons maintenant un pas plus loin en retournant notre propre pentesting IA contre nous-mêmes, y compris une analyse en crystal box de notre propre code source, où les agents de test ont un accès complet au code. Nous menons cette analyse avec plusieurs modèles différents, afin que les angles morts de l’un passent moins probablement inaperçus.

Le même principe façonne le pentesting IA que nous apportons à nos partenaires, où l’IA réalise le test et le consultant du partenaire le signe. Les développeurs semblent partager cet instinct. Dans la Developer Survey 2026 de Stack Overflow, près de la moitié des répondants disaient faire confiance à la sortie de l’IA lorsqu’ils peuvent la vérifier, tandis que seulement 6,6 pour cent confieraient à l’IA une décision importante.

Pourquoi davantage de fonctionnalités ne signifie-t-il pas automatiquement plus de valeur ?

La seconde préoccupation est moins technique mais tout aussi réelle. No Jitter a récemment décrit un « déluge de fonctionnalités » dans les logiciels de communication, où les éditeurs publient des centaines de nouvelles fonctionnalités chaque année tandis que l’adoption reste à la traîne. Les benchmarks de Pendo suggèrent qu’environ 80 pour cent des fonctionnalités construites n’atteignent jamais une adoption significative, et que 6,4 pour cent des fonctionnalités génèrent 80 pour cent de tous les clics. Ce schéma existait bien avant l’IA. L’IA rend simplement moins coûteux de le répéter.

Guardian360 a toujours essayé d’offrir une plateforme qu’un MSP peut expliquer à un membre de son conseil d’administration en quelques minutes. Chaque fonctionnalité que nous ajoutons rend cela plus difficile. Le coût de construction d’une fonctionnalité s’est effondré ; le coût de sa compréhension, non.

Nos partenaires portent déjà une complexité considérable. Une recherche de CRN, publiée par l’éditeur de sécurité Coro, a constaté que les MSPs gèrent entre 6 et 20 fournisseurs ou plus pour livrer des services de sécurité, qu’ils notent l’intégration entre ces outils à seulement 6,2 sur 10, et que seuls 7 pour cent sont satisfaits du retour sur leurs outils de sécurité. La dernière chose dont ils ont besoin de notre part, c’est d’une couche de complexité supplémentaire, aussi bien intentionnée soit-elle.

Où le goulot d’étranglement s’est-il déplacé ?

La recherche DORA de Google offre une grille de lecture utile. Son rapport 2025 a constaté, pour la première fois, une relation positive entre l’adoption de l’IA et le débit de livraison, mais l’adoption de l’IA restait corrélée à une moindre stabilité de livraison : davantage d’échecs liés aux changements, davantage de reprises et des temps de rétablissement plus longs. DORA a également conclu que l’IA tend à refléter et à amplifier les traits organisationnels existants, pour le meilleur et pour le pire.

J’élargirais cette observation au-delà de l’équipe de développement. Une fonctionnalité ne crée de la valeur que lorsqu’un partenaire la comprend, la configure, l’explique à un client et bâtit un service autour d’elle. Cette chaîne avance à vitesse humaine. L’IA accélère le premier maillon et laisse le reste intact, ce qui signifie que la file d’attente se déplace simplement vers l’aval, vers nos partenaires et leurs clients.

L’enquête de Stack Overflow pointe dans la même direction : les gens font confiance à ce qu’ils peuvent vérifier. Un partenaire qui n’a jamais vu une fonctionnalité fonctionner ne peut pas la vérifier, ne peut pas l’expliquer et ne la vendra pas.

Devrions-nous simplement ralentir ?

Certains partenaires défendraient exactement cela : arrêtez un moment, stabilisez, laissez-nous rattraper notre retard. C’est un argument légitime et je l’approuve en partie. Un éditeur qui publie plus vite que son canal ne peut suivre optimise pour sa propre satisfaction, pas pour celle de ses partenaires.

Pourtant, ralentir artificiellement gâcherait une opportunité que les petits éditeurs européens obtiennent rarement. La réponse, je crois, est la discipline plutôt que le freinage. Cela signifie décider ce qu’il ne faut pas livrer, traiter la simplicité comme une exigence de conception plutôt que comme une arrière-pensée, et impliquer les partenaires avant qu’une fonctionnalité ne soit terminée plutôt qu’après.

Une partie de cette discipline est intégrée à la plateforme elle-même. Nous introduisons les workspaces : plutôt que de présenter chaque fonctionnalité sur un seul écran, nous regroupons les fonctionnalités par tâche, de sorte qu’un partenaire ne voie que ce que le travail en cours exige. L’interface pilotée par l’IA va plus loin. Les pages, les rapports et la navigation deviennent des définitions plutôt que du code, et un agent construit la vue qu’un utilisateur demande dans les limites de son rôle. Ce n’est plus un concept. Nous le montrerons en fonctionnement le 3 novembre, et nous voulons un retour honnête de nos partenaires sur la question de savoir si cela les aide réellement.

Il existe une seconde manière de contenir la complexité : laisser la plateforme accomplir une plus grande partie du travail. Aujourd’hui, Lighthouse vous indique ce qui pourrait être amélioré. À l’avenir, il le corrigera aussi, là où le partenaire et son client l’y autorisent. Chaque tâche que la plateforme prend en charge est une tâche qu’un partenaire n’a plus à apprendre, à expliquer ou à planifier.

Pourquoi nous ouvrons les portes de la salle de contrôle

Le logo de Guardian360 contient un phare, et la métaphore n’a jamais semblé aussi juste. Un phare n’est utile que si sa lumière atteint le rivage. Nous pouvons construire la lumière la plus éclatante du monde, mais ce sont nos partenaires qui la portent jusqu’à leurs clients.

C’est pourquoi nous organisons « Un regard depuis la salle de contrôle » le mardi 3 novembre 2026, de 09:30 à 13:00 au Van der Valk Hotel à Woerden. Nous montrerons ce que nous avons construit, en fonctionnement réel plutôt que sur des diapositives, et nous donnerons un premier aperçu de ce que Guardian360 livrera en 2027. La participation est gratuite, il y a de la place pour environ 50 invités, et les inscriptions sont ouvertes jusqu’au 30 octobre. Plus que les démonstrations, c’est la conversation que je valorise. Je préfère entendre le 3 novembre que quelque chose est trop complexe plutôt que de le découvrir dans les chiffres d’adoption un an plus tard.

Alors, quelle est votre contrainte aujourd’hui ?

Si construire n’est plus votre contrainte non plus, et pour beaucoup de MSPs ce moment est plus proche qu’il n’y paraît, laquelle l’est ? Pour nous, la réponse est claire. Lorsque construire n’est plus rare, c’est la mise en œuvre qui le devient. C’est là que commence le plus difficile, et c’est un travail que nous ne pouvons accomplir qu’ensemble avec nos partenaires.

Sources

• Veracode: 2026 GenAI Code Security Report: AI Is Writing More of Your Code but Security Hasn’t Caught Up (July 2026)
• IOActive: The Security Gap in AI-Generated Code (April 2026)
• Cloud Security Alliance: Vibe Coding Security Debt: AI-Generated Vulnerabilities at Scale (April 2026)
• IT Brief UK: Stack Overflow survey finds developers wary of AI tools (October 2026)
• Google Cloud / DORA: Announcing the 2025 DORA report: State of AI-assisted Software Development
• No Jitter: Vendors ship thousands of features, users adopt dozens (July 2026)
• Coro / CRN: Your Tool Stack Is Eating Your Margins (August 2026)
• Guardian360: A view from the control room, event 3 November 2026