Pourquoi les RSSI devraient s’opposer à la méthode Agile dans l’IT

« Agile » est un terme à la mode dans le domaine de l’informatique. D’une bonne intention pour améliorer la qualité des logiciels et la vitesse de livraison, il a été de plus en plus mal vendu au cours des deux dernières décennies comme une panacée pour guérir tous les maux de l’informatique. La méthodologie donne la priorité à l’autonomie, à la rapidité de livraison et à une éthique du « move fast, fail fast », c’est-à-dire « aller vite, échouer vite », ce qui suffit à faire grimacer n’importe quel RSSI. Christophe Jolly, Directeur Régional Europe du Sud chez Vectra AI partage son expertise sur le sujet.

Agent de changement ou agent de malheur ?

La méthode Agile a son utilité. En tant qu’approche itérative du développement de logiciels, elle peut aider les équipes à accélérer la mise sur le marché et à éliminer les obstacles. Elle peut être particulièrement efficace pour les petites entreprises et équipes réduites. Mais elle est peu évolutive et n’est pas habituée aux environnements hétérogènes complexes. Elle ne transformera certainement pas une équipe de livraison défaillante en une équipe efficace.

Pourtant, la méthode Agile est de plus en plus adoptée comme modèle d’exploitation pour l’ensemble du secteur technologique, afin de favoriser la transformation partout, des services d’assistance aux centres de données. Les DSI évangélistes sont encouragés par une entreprise qui ne comprend pas ses nuances. La moitié des entreprises utilisent les pratiques Agile pour la transformation depuis au moins trois ans. Mais est-ce toujours approprié ?

Dites simplement « non »

Une demande classique : « Pouvez-vous me donner une exception d’acceptation de risque/sécurité ? », qui pourrait être plus précisément traduite par : « Pouvez-vous compromettre la sécurité pour m’aider à atteindre mes objectifs de livraison Agile ? ». Une réponse appropriée de la part du RSSI serait : « Bien sûr, à condition que vous soyez prêt à assumer l’entière responsabilité en cas de problème ».

La sécurité doit être acceptée comme une exigence fonctionnelle obligatoire de tout projet. Il est moins coûteux, plus facile et plus sûr de l’intégrer dès le départ que de la mettre à niveau. Pourtant, il est étonnant de constater combien de projets Agile font de « l’approbation de la sécurité » la dernière tâche du sprint, ce qui entraîne inévitablement des retards.

La conformité réglementaire de base n’est pratiquement pas pertinente dans le paysage actuel des menaces. Des tests sont donc à effectuer avec des outils performants et, le cas échéant, avec des équipes d’experts indépendants. Les RSSI ont besoin d’outils capables de surveiller de près les environnements, les erreurs et les mauvaises configurations pour atténuer efficacement les risques. L’entreprise au sens large doit comprendre qu’un produit n’est pas complet tant que toutes les exigences de sécurité ne sont pas satisfaites.

La réalité est que les RSSI sont la conscience de l’entreprise. Pour que les projets Agile réussissent, il faut parfois ralentir un peu les choses et poser des questions difficiles. Il faut aussi parfois remettre en question la foi dogmatique de nombreux DSI et de leurs équipes.

C’est normal d’être parfois le « méchant ». Dites non à la méthode Agile lorsque de meilleures solutions existent.