Fast, Good, Cheap : le triangle de fer appliqué à l'infogérance IT

Dans le monde du conseil, du développement logiciel et de l'infogérance, une maxime circule depuis des décennies et résiste à toutes les modes technologiques : « Rapide, bon, pas cher. Choisissez-en deux. » Ce principe, souvent appelé triangle de fer, triangle de projet ou Project Management Triangle, est aussi frustrant qu'il est vrai. Il s'applique à toutes les décisions d'infrastructure informatique : héberger un site, sécuriser un serveur, migrer une base de données, reprendre l'exploitation d'un parc existant. Comprendre ce triangle, c'est arrêter de croire aux promesses miracles et commencer à piloter ses choix techniques avec lucidité.

Dans cet article, nous décomposons chacune des six combinaisons possibles du triangle (fast+cheap, good+cheap, good+fast, etc.) en les traduisant en situations concrètes d'infrastructure IT. Nous montrons pourquoi la combinaison « fast + good + cheap » est mathématiquement impossible, et surtout comment un décideur ou une équipe technique peut arbitrer ses priorités sans se mentir sur les conséquences.

1. Le triangle de fer : origine et fondements

Le triangle de fer (iron triangle) est un modèle de gestion de projet apparu dans les années 1950-1960 dans les grands programmes industriels et militaires. Il formalise une contrainte structurelle : tout projet est défini par trois paramètres interdépendants — le périmètre (ou qualité), le temps (délai) et le coût (budget). Modifier un seul de ces paramètres impacte mécaniquement les deux autres. Vouloir tout optimiser simultanément revient à surestimer la réalité physique et humaine du travail.

Appliqué à l'informatique, le triangle se reformule ainsi : • **Fast (rapide)** : la vitesse de mise en œuvre ou de résolution. • **Good (bon)** : la qualité, la robustesse, la sécurité, la tenue en charge. • **Cheap (peu coûteux)** : le budget alloué, en argent et en ressources humaines. La règle d'or est simple : **on peut optimiser deux axes, mais le troisième paiera**. Toute proposition qui prétend livrer les trois à la fois cache nécessairement un coût différé : dette technique, insécurité, maintenance sous-estimée ou dépendance à un fournisseur.

Il n'existe pas de projet rapide, bon marché et de qualité. Il existe des projets dont on a caché le vrai coût quelque part dans le futur.

2. Fast + Cheap = Mediocre : le piège de la course au prix

C'est la combinaison la plus fréquente dans les appels d'offres d'infogérance et les projets de sites web. Le client veut une solution tout de suite et à moindre coût. Le prestataire, pour rester rentable, rogne sur tout ce qui ne se voit pas immédiatement : audits de sécurité, sauvegardes testées, supervision, documentation, redondance. Le résultat est en ligne rapidement, mais fragile. À la première panne, à la première attaque, ou au premier pic de trafic, l'édifice s'effondre.

En infrastructure, cette combinaison se traduit typiquement par : • Un serveur mutualisé surchargé sans isolation des pools PHP. • Un WordPress installé en dix minutes avec vingt plugins gratuits non maintenus. • Des sauvegardes quotidiennes stockées sur le même disque que la production. • Aucune supervision sérieuse en dehors d'un ping occasionnel.

# Symptôme classique du « fast + cheap » : une pile LAMP par défaut
# Apache + mod_php + MySQL root sans mot de passe + WordPress en 777
chmod -R 777 /var/www/html   # 🚨 Faille majeure : ne jamais faire ça
mysql -u root -e "GRANT ALL PRIVILEGES ON *.* TO 'wp'@'%' IDENTIFIED BY 'password';"
# Résultat : site livré vite, à petit prix… et compromis en 48h.

Le vrai coût de cette approche apparaît généralement dans les six à douze mois suivants : incident de sécurité, perte de données, refonte complète à financer en urgence, perte de confiance des clients. Le « cheap » du départ devient ruineux.

3. Good + Cheap = Take a while : l'approche artisanale

La seconde combinaison est celle de l'artisan consciencieux. On veut du travail bien fait, sans exploser le budget. C'est possible, mais cela prend du temps. En infogérance, cela se traduit par des projets étalés sur plusieurs mois, des phases de test longues, une documentation progressive, un durcissement système réalisé étape par étape. La qualité est au rendez-vous, mais le temps de mise sur le marché s'allonge.

Cette approche est parfaitement adaptée aux projets internes sans pression concurrentielle forte : migration d'un annuaire interne, refonte d'un intranet, durcissement progressif d'un parc serveur. En revanche, elle est inadaptée à un lancement commercial urgent ou à une réponse à incident.

Un projet « good + cheap » n'est pas un projet lent : c'est un projet dont on a accepté de ne pas fixer la date de fin à l'avance.

# Illustration d'un durcissement progressif (good + cheap)
# Chaque semaine, on traite un axe : gains de sécurité cumulatifs, coût étalé

# Semaine 1 : SSH par clés uniquement
sed -i 's/^#*PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
systemctl reload ssh

# Semaine 2 : pare-feu UFW
ufw default deny incoming && ufw allow OpenSSH && ufw allow 443/tcp && ufw enable

# Semaine 3 : Fail2ban + supervision
apt install -y fail2ban prometheus-node-exporter

# Semaine 4 : sauvegardes chiffrées hors site
# (Restic + S3 souverain — mise en place longue mais peu coûteuse)

4. Good + Fast = Costly : l'excellence a un prix

La troisième combinaison est celle des projets critiques à forte valeur métier. On veut du robuste, du sécurisé, du supervisé, livré vite. C'est possible, à condition d'y mettre le budget : expertise senior, infrastructure dédiée, redondance, astreinte 24/7, tests de charge, audits de sécurité en parallèle du développement. C'est le modèle des grands lancements e-commerce, des plateformes financières ou des services de santé numériques.

En infrastructure, cela se traduit par : • Un cluster haute disponibilité (Proxmox, K3s multi-nœuds, load balancer). • Des sauvegardes chiffrées, dédupliquées, répliquées dans deux régions distinctes. • Une supervision 24/7 avec astreinte et procédures d'escalade formalisées. • Un WAF, un pare-feu applicatif et une veille CVE automatisée.

# Exemple de socle « good + fast » : infrastructure redondée et supervisée
# Coût élevé, mais déploiement reproductible en quelques heures via Ansible

- name: Provisionner un cluster K3s HA
  hosts: k3s_servers
  become: yes
  tasks:
    - name: Installer K3s en mode embedded etcd
      shell: |
        curl -sfL https://get.k3s.io | \
          INSTALL_K3S_EXEC="server --cluster-init" sh -
    - name: Déployer node_exporter
      apt:
        name: prometheus-node-exporter
        state: present

Cette combinaison n'est pas « chère » au sens où elle serait surfacturée : elle est chère parce qu'elle mobilise réellement plus de compétences, plus d'infrastructure et plus d'attention humaine. Le prix reflète la valeur réelle produite.

5. Fast = Mediocre + Costly : l'urgence coûte cher

Cette formulation, moins intuitive, décrit une réalité brutale de l'infogérance : lorsqu'on exige une vitesse maximale sans accepter le temps nécessaire à la qualité, on obtient à la fois de la médiocrité **et** une facture élevée. Pourquoi ? Parce que la vitesse forcée mobilise des ressources premium (astreinte nuit, experts seniors, contournements à chaud) qui coûtent cher, tout en produisant un résultat fragile qu'il faudra reprendre plus tard.

C'est le scénario classique de l'incident de production traité dans l'urgence : on redémarre brutalement le serveur, on désactive un module de sécurité pour débloquer le service, on commente du code pour contourner un bug. Le service revient en quelques minutes… au prix d'une dette technique et d'une exposition de sécurité qui coûteront bien plus cher à corriger.

Chaque raccourci pris dans l'urgence se paie deux fois : une fois en facture immédiate, une fois en dette technique différée.

# Anti-pattern « fast = mediore + costly »
# Désactiver SELinux pour faire passer une application coûte que coûte
setenforce 0
sed -i 's/^SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config
# Résultat : débloqué en 2 minutes, mais machine exposée et reprise de dette garantie.

6. Good = Costly + Slower : le prix de la qualité

Vouloir de la qualité sans compromis, c'est accepter deux conséquences : un coût plus élevé et un délai plus long. En cybersécurité, cela signifie : mener un audit externe avant mise en production, faire des revues de code, tester les plans de reprise, documenter chaque procédure, former les équipes. Chacune de ces étapes a un coût direct et rallonge le calendrier.

C'est la combinaison choisie par les organisations qui considèrent l'informatique comme un actif stratégique et non comme un centre de coût. Elle est souvent mal comprise en interne : « pourquoi ça prend aussi longtemps ? pourquoi ça coûte aussi cher ? ». La réponse est simple : parce que la qualité a un prix mesurable, tandis que la non-qualité a un coût imprévisible.

# Exemple : pipeline CI/CD qui privilégie la qualité (good)
# Coût : temps de build plus long. Bénéfice : zéro régression en prod.

stages:
  - lint
  - test
  - security-scan
  - deploy

security-scan:
  stage: security-scan
  script:
    - trivy image --exit-code 1 --severity CRITICAL $IMAGE
    - gitleaks detect --source . --no-git
    - composer audit
  allow_failure: false

7. Cheap = Slow + Mediocre : le vrai coût du low-cost

C'est la combinaison la plus répandue dans les offres d'infogérance « à 50 € par mois » ou de développement web « à 500 € le site ». Sur le papier, c'est attractif. Dans la réalité, on obtient à la fois de la lenteur (parce que les ressources sont mutualisées, les tickets s'empilent, les intervenants changent) et de la médiocrité (parce que personne n'a le temps de faire les audits de sécurité, les sauvegardes testées, la supervision fine).

Le low-cost en informatique fonctionne dans deux cas précis : • Des projets non critiques, où l'interruption de service n'a pas d'impact métier direct. • Des phases de test ou de pré-production, où la robustesse n'est pas encore requise. En dehors de ces cas, il faut comprendre que le « cheap » est presque toujours une illusion comptable : le coût réel apparaît plus tard, sous forme d'incidents, de refontes, de pertes de données ou de clients.

Le low-cost n'élimine pas les coûts : il les déplace. La question est de savoir si vous préférez les payer maintenant, à froid, ou plus tard, dans l'urgence.

8. Fast + Good + Cheap = Impossible : la démonstration

La démonstration du triangle est simple. Supposons qu'un projet veuille être simultanément rapide (fast), de qualité (good) et peu coûteux (cheap). • Pour être **rapide**, il faut paralléliser les tâches et mobiliser plus de ressources : des experts seniors, des astreintes, des environnements provisionnés en quelques minutes. Or ces ressources coûtent cher. On ne peut donc pas être « cheap » en étant « fast ». • Pour être **cheap**, il faut mutualiser les ressources, économiser sur les audits, limiter le nombre d'intervenants et étaler le calendrier. On ne peut donc pas être « fast » en étant « cheap ». • Pour être **good**, il faut du temps de test, de documentation, de revue, et des compétences rares. On ne peut donc pas être simultanément « fast » et « good » sans budget élevé.

Chaque tentative d'optimiser les trois axes à la fois finit par en sacrifier un en silence. L'honnêteté technique consiste à l'annoncer explicitement dès le départ, plutôt que de le laisser découvrir par le client au moment du premier incident.

Fast + Good + Cheap = Impossible. Ce n'est pas une opinion, c'est une contrainte mathématique du travail humain et de la physique des systèmes.

9. Comment choisir ses deux priorités en infogérance

La bonne pratique, en agence ou en infogérance, n'est pas de promettre les trois, mais de **choisir explicitement deux priorités** avec le client et d'accepter le compromis sur la troisième. Ce choix dépend de trois questions : 1. **Quel est l'impact métier d'une interruption de service ?** Si l'activité s'arrête, la priorité est *fast + good* (quitte à ce que ce soit cher). 2. **Quel est l'impact métier d'une faille de sécurité ou d'une perte de données ?** Si des données personnelles ou financières sont en jeu, la priorité est *good + cheap* (quitte à ce que ce soit plus long). 3. **Quel est le budget réellement disponible, et sur quelle durée ?** Si le budget est contraint, on accepte *cheap + slow* sur les projets non critiques, et on réserve le budget *good + fast* aux projets stratégiques.

En pratique, cela se traduit par une matrice de décision à trois colonnes : projet critique (fast+good), projet de transformation (good+cheap), projet exploratoire (cheap+slow). Chaque projet doit être classé dans l'une de ces cases **avant** d'être lancé, et non découvert après les premières difficultés.

# Exemple de matrice de décision formalisée dans un projet d'infogérance

| Projet                          | Priorité 1 | Priorité 2 | Compromis accepté |
|---------------------------------|------------|------------|--------------------|
| Portail e-commerce              | Fast       | Good       | Budget élevé       |
| Migration ERP                   | Good       | Cheap      | Délai long         |
| Refonte intranet                | Cheap      | Slow       | Qualité standard   |
| Réponse à incident de sécurité  | Fast       | Good       | Coût d'astreinte   |

10. Le vrai coût caché des compromis

Le piège classique de l'arbitrage du triangle est de ne compter que le coût immédiat et de ne pas mesurer le coût différé. Une décision *fast + cheap* sur un projet critique peut sembler économiser 30 000 € sur le budget initial. Si elle conduit à un incident de sécurité six mois plus tard, la facture réelle sera plutôt de 150 000 € (interruption, forensique, communication, refonte) sans compter la perte de confiance. Le TCO (Total Cost of Ownership) estime ce coût global sur trois à cinq ans, et il révèle presque toujours que le compromis initial était économiquement faux.

# Illustration simplifiée de calcul TCO sur 3 ans (en euros)

# Option A : fast + cheap (audit de sécurité sauté, sauvegardes non testées)
Projet initial       :  40 000
Incident sécurité an 2 : 120 000
Refonte partielle an 2 :  35 000
Coût total 3 ans       : 195 000

# Option B : good + cheap (projet plus long, audité et sauvegardé)
Projet initial       :  70 000
Incident majeur      :       0
Maintenance an 2-3   :  30 000
Coût total 3 ans       : 100 000

# Conclusion : le « cheap » initial coûte près du double sur 3 ans.

Le vrai coût d'un projet informatique n'est pas son prix de livraison : c'est la somme de son prix de livraison et du coût de tous les incidents qu'il va provoquer dans les trois années suivantes.

11. Appliquer le triangle à sa propre organisation

Le triangle de fer ne s'applique pas seulement aux projets clients : il s'applique aussi aux décisions internes. Une équipe technique qui veut à la fois traiter les tickets urgents (fast), sécuriser son parc (good) et ne pas recruter (cheap) se retrouve mécaniquement en situation d'épuisement, avec une dette de sécurité qui s'accumule. Reconnaître le triangle, c'est accepter de prioriser explicitement, de refuser certaines demandes, et de documenter les compromis.

Chez OWL SYSTEMS, cette lucidité se traduit par trois engagements concrets : • **Toujours annoncer la troisième dimension sacrifiée.** Un client doit savoir s'il achète de la vitesse, de la robustesse ou de l'économie — et ce qu'il paiera en échange. • **Réserver le *fast + good* aux projets critiques.** Le reste du temps, privilégier *good + cheap* avec un calendrier réaliste. • **Refuser les promesses impossibles.** Un prestataire qui vous promet *fast + good + cheap* vous vend soit de l'incompétence, soit une dette technique différée que vous découvrirez trop tard.

La maturité technique d'une organisation se mesure à sa capacité à nommer ses compromis, pas à sa capacité à les cacher.