Je suis parti quinze jours. À mon retour, mon iMac avait décidé de mourir.
Enfin, c'est ce que j'ai cru.
Le ventilateur tournait à fond en permanence, la machine ramait, le processeur fonctionnait à peine au quart de sa fréquence normale. Et la charge système avait atteint un chiffre absurde : 634. Sur une machine à dix cœurs, ce n'est plus une machine qui travaille, c'est un embouteillage.
Premier réflexe : regarder les prix d'un remplaçant. Deuxième réflexe : essayer de comprendre avant de sortir la carte bancaire.
C'est là que les ennuis ont commencé. Pendant deux jours, presque toutes les mesures que j'ai faites racontaient une histoire plausible. Simplement, ce n'était jamais la bonne.
Première piste : la machine pense qu'elle surchauffe
Sur un Mac, le système surveille les températures en permanence et peut ralentir brutalement le processeur pour se protéger. Le mien était limité à 26 % de sa fréquence normale, ventilateur hurlant. Conclusion évidente : surchauffe.
Sauf qu'au même moment, la température interne était de 63 °C. Pas froide, mais très loin des seuils auxquels un processeur de cette génération commence à se brider. La machine se comportait comme si elle brûlait alors qu'elle était simplement chaude.
J'ai donc suspecté le contrôleur thermique. Reset complet, alimentation coupée, redémarrage. La bride disparaît immédiatement : 100 % de fréquence, machine fluide, problème réglé.
Cinq heures plus tard, elle était de nouveau limitée à 54 %.
C'est le genre de moment où j'essaie de ne pas tomber amoureux de mon diagnostic. Un correctif qui fonctionne quelques heures ne prouve pas qu'on a trouvé la cause — seulement qu'on a modifié quelque chose.
Deuxième piste : six ans de poussière
L'iMac a six ans. Une grande dalle, un ventilateur, des milliers d'heures d'air aspiré : l'hypothèse était presque trop évidente. D'autant que les journaux système contenaient un élément inquiétant — pendant mon absence, la machine avait subi deux mises en veille forcées pour cause thermique, en pleine nuit, sans personne devant.
J'étais quasiment convaincu qu'il faudrait démonter l'écran, nettoyer le refroidissement et refaire la pâte thermique. J'étais à deux doigts de le faire.
Mais démonter une dalle collée sur une intuition me semblait être une mauvaise méthode. J'ai donc laissé la machine tranquille une nuit entière : pas de compilation, pas d'outils de développement, juste une mesure de température toutes les cinq minutes.
Au matin, 98 relevés. La température était descendue à 42 °C et y était restée toute la nuit, sans aucune limitation du processeur.
Un refroidissement réellement bouché ne se comporte pas comme ça. Deuxième hypothèse éliminée.
Troisième piste : la canicule
Il faisait très chaud, mon bureau n'est pas climatisé, et un ordinateur refroidi à l'air dépend directement de la température de la pièce. Dix degrés de plus dans la pièce, ce sont dix degrés qu'il faut retrouver quelque part dans le système.
L'hypothèse tenait. Elle expliquait même une partie du problème. Mais pas tout : certains matins, dix minutes après le démarrage, le ventilateur repartait déjà presque à fond, avant même que j'aie commencé à travailler.
Et c'est là que j'ai réalisé que mon expérience de la nuit précédente était imparfaite. J'avais changé deux choses en même temps : la température de la pièce avait baissé, mais l'écran s'était aussi éteint.
Deux variables, une seule mesure, donc aucune conclusion fiable. C'est une erreur classique — obtenir le résultat qu'on espérait et arrêter de chercher. J'avais eu raison, pour de mauvaises raisons.
Puis j'ai changé mon fond d'écran
Pas pour réparer l'ordinateur. Juste pour tester.
L'iMac utilisait l'économiseur d'écran comme fond d'écran : derrière mes fenêtres, une animation vidéo tournait en permanence. Je suis passé sur une image fixe, et quelques instants plus tard le ventilateur a commencé à ralentir.
J'ai d'abord pensé à une coïncidence. Puis j'ai regardé la carte graphique : 84 % de charge. Avec une image fixe, 0 %.
Voilà ce que je n'avais pas vu pendant tout ce temps. Le processeur était quasiment au repos, mais la carte graphique décodait en permanence une vidéo affichée sur une dalle de quinze millions de pixels. Le moniteur d'activité donnait l'impression d'une machine calme. Elle ne l'était pas.
Le ventilateur ne dysfonctionnait pas : il faisait exactement son travail. Et quelques minutes plus tôt, j'étais prêt à démonter physiquement l'ordinateur. Tout ça pour un fond d'écran.
Mais ce n'était toujours pas terminé.
Parce qu'il n'y avait pas une panne
Il y en avait plusieurs — et c'est probablement ce qui a rendu le diagnostic aussi trompeur.
Le ventilateur venait de la carte graphique, mais il restait cette charge système délirante. En remontant les processus, j'ai trouvé une tâche de nettoyage automatique censée se lancer toutes les quinze minutes. Rien d'anormal jusque-là — sauf qu'une exécution mettait environ une heure quarante à se terminer.
Toutes les quinze minutes, une nouvelle instance démarrait donc avant que la précédente ait fini. Puis une autre. Quand j'ai regardé, plusieurs parcouraient le disque simultanément, et le journal était encore plus parlant : plus aucune exécution complète depuis près de trois semaines.
Le programme tournait. Il ne plantait pas, ne renvoyait aucune erreur. Il travaillait simplement dans le vide.
Et il y avait encore autre chose. Notre chaîne d'intégration continue utilisait elle aussi cette machine, et chaque outil était correctement configuré — pris individuellement. Chacun voyait dix cœurs disponibles, chacun considérait donc qu'il pouvait lancer une vingtaine de processus. Avec quatre tâches parallèles, je me retrouvais avec environ 80 processus concurrents sur dix cœurs.
Aucun réglage n'était absurde. C'est leur combinaison qui l'était.
C'est une distinction importante dans les infrastructures modernes : beaucoup de problèmes ne viennent plus d'un composant cassé, mais de plusieurs composants qui fonctionnent exactement comme prévu.
Le vrai problème était ailleurs
À ce stade la machine était redevenue silencieuse, et j'aurais pu m'arrêter là. Mais une question me gênait davantage que le ventilateur : pourquoi notre surveillance n'avait-elle rien vu ?
Nous avons justement construit une infrastructure où des agents, des runners et des tâches automatiques surveillent nos machines et remontent les anomalies. C'est une manière de travailler que nous utilisons partout chez Domaine du Net, et que j'ai détaillée dans un article sur notre méthode : automatiser ce qui peut l'être, mesurer ce qui doit l'être, et garder assez de traces pour comprendre ce qui s'est passé.
En théorie, une machine avec une charge de 634 n'aurait jamais dû rester silencieuse pendant deux jours. J'ai donc commencé à tester le système de surveillance lui-même — et j'ai découvert quelque chose de bien plus intéressant que la panne initiale.
La surveillance fonctionnait parfaitement. Elle s'exécutait à l'heure prévue, terminait sans erreur, remontait un statut vert.
Il y avait juste un petit problème : elle ne surveillait pas l'iMac.
Quelques mois plus tôt, j'avais ajouté une règle pour éviter qu'un autre outil ne perturbe mes sessions de travail sur cette machine. Cette exclusion avait ensuite été réutilisée dans plusieurs listes. Dont celle du monitoring. Chaque jour, le programme se lançait donc correctement sur une liste vide, et déclarait que tout allait bien.
Techniquement, il avait raison. Il n'avait trouvé aucun problème parmi les zéro machine qu'il avait examinée.
Quand « succès » ne veut plus rien dire
En remontant plus loin, j'en ai trouvé trois autres du même genre.
Des scripts distants étaient envoyés correctement sur les machines, mais pas exécutés par l'interpréteur prévu. Une commande simple fonctionnait ; une condition ou une boucle échouait silencieusement. Résultat : les sondes complexes ne renvoyaient rien, et ce vide était interprété comme « rien à signaler ».
Deux autres tâches de maintenance avaient exactement le même défaut conceptuel. Elles démarraient, ne trouvaient aucune machine, terminaient avec succès. Depuis avril.
Aucun test automatisé ne les avait détectées, et je ne pense pas que ce soit une faiblesse des tests — c'est leur limite. Un test vérifie qu'un programme fait correctement ce qu'on lui demande. Il ne peut pas savoir si on lui demande de regarder au bon endroit.
C'est pour cette raison que je crois beaucoup aux tests sur le réel, aux métriques et à l'observabilité. Pas seulement « mon programme a-t-il terminé ? », mais « qu'a-t-il réellement fait ? ».
Le silence n'est pas un état sûr
C'est la vraie leçon de ces deux journées.
Notre monitoring ne rapporte plus uniquement le nombre de problèmes détectés : il indique aussi combien de machines ont réellement été examinées. Une surveillance qui contrôle dix machines et ne trouve rien peut dire « tout va bien ». Une surveillance qui en contrôle zéro doit dire « je n'ai rien vérifié ».
Ça semble évident une fois écrit. Ça l'est beaucoup moins quand un système renvoie un joli statut vert depuis plusieurs mois.
Même logique pour les machines qui cessent de répondre. Avant, l'absence de réponse produisait simplement une absence de donnée. Désormais, cette absence est elle-même une donnée — et potentiellement une alerte.
La CI a également été bridée : aucun outil ne peut plus considérer qu'il possède seul toutes les ressources de la machine. C'est le même socle d'intégration continue que nous utilisons sur tous nos projets. Parce que là encore, le problème ne venait pas d'un mauvais réglage, mais de plusieurs bons réglages qui ignoraient l'existence des autres.
Ce que ces deux jours m'ont rappelé
Quand je construis une infrastructure, j'essaie d'appliquer trois règles simples.
Mesurer avant de corriger. J'aurais pu démonter l'iMac dès la première heure — tout semblait indiquer un problème thermique. Les mesures m'en ont empêché.
Faire varier une seule chose à la fois. Température de la pièce, écran, charge processeur, carte graphique : changer deux paramètres simultanément produit des certitudes complètement fausses.
Ne jamais confondre absence d'erreur et preuve de fonctionnement. C'est la plus importante. Un script qui termine correctement n'a pas nécessairement travaillé. Une sonde silencieuse n'a pas nécessairement vérifié quoi que ce soit. Un agent qui ne remonte rien n'a pas nécessairement réussi.
Avec les systèmes modernes — automatisation, CI/CD, agents IA, tâches planifiées — cette distinction devient de plus en plus importante. On automatise énormément chez Domaine du Net, et c'est précisément pour ça que nous essayons de rendre cette automatisation observable. Une infrastructure robuste n'est pas simplement une infrastructure qui fonctionne : c'est une infrastructure capable de vous montrer qu'elle fonctionne réellement.
Au final, mon iMac n'était pas mort. Il avait un fond d'écran beaucoup trop ambitieux, une tâche automatique devenue incontrôlable et une CI un peu trop enthousiaste. Et le système chargé de me prévenir était convaincu que tout allait parfaitement bien.
Depuis, le bureau est beaucoup plus silencieux. Il reste un composant que je n'ai toujours pas réussi à automatiser : la climatisation.
À très vite, Julien