Tout rame, pourtant le serveur est une grosse machine Le serveur est saturé, pourtant la machine est grosse
Ce que vous voyez Le site met dix secondes à répondre dès 9 h. / Le serveur a été changé l'an dernier, ça n'a rien changé. load average: 212.40 · mysql: Too many connections / php-fpm: server reached pm.max_children · swap 100%
On regarde Le vrai état de la machine : demandes en attente, visiteurs connectés, disques, mémoire. Pas le voyant vert qui dit que tout va bien. Les compteurs réels : connexions, files d'attente, entrées-sorties, mémoire par processus. Pas la jauge CPU du tableau de bord.
On trouve souvent Des réglages d'usine jamais adaptés : une base de données prévue pour une machine dix fois plus petite, un serveur web qui ne sert que cinq visiteurs à la fois, de la mémoire gaspillée. Des réglages d'usine jamais touchés : pool MySQL dimensionné pour 2 Go, PHP-FPM limité à 5 workers, noyau avec ses files par défaut, un swap qui mange les disques.
On fait On mesure, on règle chaque programme, on teste en pleine affluence, on note chaque réglage et pourquoi. On mesure, on règle service par service, on vérifie sous charge, on documente chaque valeur et pourquoi.
Résultat La même machine encaisse dix fois plus, sans rien racheter. Et vous savez désormais où regarder. La même machine absorbe dix fois plus, sans rachat de matériel. Et vous savez désormais où regarder.
Des appels fantômes, une facture de téléphone qui explose Des appels fantômes, une facture télécom qui explose
Ce que vous voyez 2 310 tentatives d'intrusion par seconde sur votre standard. / 412 appels vers la Somalie entre 2 h 10 et 2 h 40. REGISTER flood 2 310 req/s · INVITE from 185.x.x.x / 412 appels vers +252 entre 02:10 et 02:40
On regarde Votre standard en direct : qui essaie d'appeler, depuis quelle ligne, vers quels pays, à quel rythme. Les captures SIP en direct avec HOMER : qui frappe, sur quel compte, vers quelles destinations, à quel rythme.
On trouve souvent Des robots ont trouvé un mot de passe faible sur votre standard, puis passé des appels surtaxés la nuit, quand personne ne regarde. Un scan automatisé qui a trouvé un compte faible ou un trunk ouvert, puis des appels surtaxés la nuit, quand personne ne regarde.
On fait On ferme la porte aux pays à risque, on limite les appels par minute, on verrouille les lignes, on coupe les numéros surtaxés, on vous prévient au moindre pic d'appels. Filtrage en amont (pare-feu, géo-blocage, limitation de débit), comptes et trunks verrouillés, destinations à risque coupées, alerte sur tout volume anormal.
Résultat L'attaque s'arrête dans l'heure. Vos vrais clients vous joignent toujours, et vous êtes prévenu dès que la prochaine commence. L'attaque s'arrête dans l'heure. La plateforme reste joignable pour vos vrais clients, et vous êtes prévenu avant la prochaine.
Écran d'erreur, le serveur ne redémarre plus Écran rouge, le serveur ne revient plus
Ce que vous voyez Lundi 8 h, écran d'erreur, le serveur ne répond plus. / On rallume : un disque et une alimentation en panne. kernel panic - not syncing · ECC uncorrectable error / RAID: volume DEGRADED · PSU2: failure
On regarde Ce que le serveur a noté juste avant de planter, puis la mémoire, les disques, la carte qui les pilote et l'alimentation. Sur place au datacenter si besoin. Les journaux du contrôleur et de l'iDRAC / iLO, les barrettes, le RAID et son cache, l'alimentation. Sur place en datacenter si besoin.
On trouve souvent Une barrette de mémoire usée, un disque abîmé qui prétend aller bien, une pile interne à plat, une alimentation fatiguée. Rarement « le serveur est mort ». Une barrette mémoire qui lâche, un disque qui ment au contrôleur, une pile de cache à plat, une alim qui tient à moitié. Rarement « le serveur est mort ».
On fait On écarte la pièce fautive, on redémarre sur ce qui est sain, on récupère vos données avant toute réinstallation. Isolation du composant fautif, remise en route sur ce qui est sain, récupération des données avant toute réinstallation.
Résultat Le serveur redémarre, vos données sont là. Et on vous dit quoi remplacer avant que ça recommence. La machine redémarre, vos données sont là. Et on vous dit ce qu'il faut remplacer avant que ça recommence.
Le stockage partagé tombe, et tous vos serveurs avec Le SAN est tombé, et tout le reste avec
Ce que vous voyez 14 serveurs bloqués d'un coup, plus rien ne s'enregistre. / Le stockage partagé ne répond plus. multipath: path sdc failed · LUN 7: not responding / 14 machines virtuelles en lecture seule
On regarde Les câbles entre vos serveurs et le stockage, ses cartes de pilotage, chaque espace de données. Les deux côtés ne disent pas toujours la même chose. Les chemins, les contrôleurs, la fabrique, l'état des LUN. Ce que voient les hôtes et ce que dit la baie, qui ne sont pas toujours d'accord.
On trouve souvent Une carte de secours qui n'a pas pris le relais, un double câblage mal réglé dès l'installation, un logiciel interne qui refuse le second câble. Un contrôleur en bascule qui n'a pas basculé, un multipath mal configuré depuis le départ, un firmware qui ne tolère pas le second chemin.
On fait On rebranche tout dans le bon ordre, on stabilise le stockage, on vérifie vos données, on relance vos serveurs un par un. Remontée des chemins dans le bon ordre, baie stabilisée, systèmes de fichiers vérifiés, machines virtuelles relancées une à une.
Résultat Tout revient, sans repartir d'une sauvegarde. Plus de vingt ans sur ce genre de machines, ça sert à ce moment-là. Tout revient sans restauration. Plus de vingt ans de baies en datacenter, ça sert exactement à ce moment-là.
La fibre d'une agence coupe tous les soirs La collecte fibre d'une agence tombe tous les soirs
Ce que vous voyez 18 h 52 : l'agence perd internet. 19 h 40 : ça revient. / Chaque jour. La ligne a sauté 214 fois, signal très faible. ge-0/0/3: carrier transitions x214 · Rx power -27 dBm / 18:52 link down · 19:40 link up · tous les jours
On regarde Le signal heure par heure, les coupures, une mesure qui dit où la fibre faiblit. Et ce qui se passe dans le local vers 19 h. La courbe de puissance optique, les transitions d'interface, la trace OTDR du lien, et ce qui se passe dans le local vers 19 h.
On trouve souvent Une fibre pincée dans l'armoire, une prise sale, un chauffage qui part à 19 h et fait bouger le câble. Parfois juste un boîtier usé, celui qui envoie le signal. Une fibre pincée dans un tiroir mal lové, un connecteur sale, un chauffage qui se déclenche à 19 h et travaille un fourreau. Parfois juste un SFP en fin de vie.
On fait On mesure la fibre avant et après. On nettoie ou refait la prise, on range l'armoire, on change le boîtier. Et une alerte si le signal baisse, pour ne plus l'apprendre par vos équipes. Mesure OTDR avant et après, nettoyage ou re-soudure, tiroir relové proprement, SFP remplacé, et un seuil d'alerte sur la puissance optique pour ne plus l'apprendre par les utilisateurs.
Résultat Signal stable, 0 coupure en 30 jours. Avec un rapport de mesure daté dans votre dossier. Rx power -7.2 dBm stable, 0 transition en 30 jours. Avec un rapport OTDR daté dans votre dossier.
Transfert de numéros bloqué, le client les perd lundi La portabilité est bloquée, le client perd ses numéros lundi
Ce que vous voyez Transfert rejeté, l'ancien opérateur ne répond pas. / Changement d'opérateur prévu lundi. Il reste deux jours. APNF: demande rejetée · opérateur donneur sans réponse / bascule prévue lundi · J-2
On regarde Le dossier, l'autorisation signée, le code de chaque numéro. Les échanges avec l'ancien opérateur, les délais légaux, l'arrivée des appels chez le nouveau. Le dossier de portabilité, le mandat, le RIO, les échanges avec l'opérateur donneur, les délais réglementaires, et le routage prévu côté receveur.
On trouve souvent Un code erroné, une raison sociale différente du contrat, un numéro oublié, un ancien opérateur qui traîne. Rien d'exotique, mais il faut savoir à qui s'adresser, et comment. Un RIO erroné, une raison sociale qui ne correspond pas au contrat, un numéro oublié dans la demande, un donneur qui traîne. Rien d'exotique, mais il faut connaître les circuits.
On fait On corrige, on relance la bonne personne chez l'ancien, on prépare l'arrivée des appels chez le nouveau. On fixe l'heure du changement avec le client, on reste là pendant. On corrige, on relance au bon niveau chez le donneur, on prépare le routage et les trunks côté receveur, on planifie la bascule avec le client, on reste en ligne pendant.
Résultat Changement lundi 10 h 02, 42 numéros transférés, 0 appel perdu. Et nos propres outils pour suivre chaque numéro jusqu'au bout. Bascule lundi 10:02, 42 numéros portés, 0 appel perdu. Et des outils maison pour suivre les flux de portabilité en continu.
La nouvelle version casse le site un vendredi sur deux Le déploiement casse la prod un vendredi sur deux
Ce que vous voyez Nouvelle version en ligne 18 h 41, le site tombe en panne. / Rétabli 19 h 30. Le développeur : « chez moi ça marche ». deploy 18:41 · nginx: 502 upstream · rollback manuel 19:30 / dev: « ça marche sur ma machine »
On regarde Comment la nouvelle version arrive sur le site, les écarts entre poste du développeur et serveur, les réglages d'usine, le journal des deux côtés. Comment le code est livré, ce qui diffère entre la machine du développeur et la production, les réglages d'usine, et les journaux des deux côtés.
On trouve souvent Un serveur qui n'a pas la même version que le poste du développeur, une tâche automatique qui tourne en double, la base de données modifiée sans sauvegarde. Et personne qui voit les deux côtés à la fois. Une version de PHP différente, un cron qui tourne en double, une migration lancée sans sauvegarde, et personne qui a la vision du code et de l'infra en même temps.
On fait Mêmes réglages partout, mise en ligne avec retour arrière testé, tâches répétitives automatisées, sauvegarde avant de toucher aux données. On reste à côté des développeurs, pas en face. Environnements alignés, pipeline de déploiement avec retour arrière testé, scripts d'exploitation, sauvegarde avant chaque migration. Et on reste à côté des développeurs, pas en face.
Résultat Mise en ligne 14 h, 0 erreur, retour arrière testé. Les développeurs gardent leur rythme, le serveur ne tremble plus. Déploiement 14:00, 0 erreur, retour arrière testé. Les développeurs gardent leur rythme, l'infra ne tremble plus.
Les commandes s'arrêtent, personne n'est prévenu Un flux métier s'arrête, et personne n'est prévenu
Ce que vous voyez Zéro commande depuis 3 h 12 du matin. / Le serveur, lui, va bien : surveillance au vert. commandes reçues: 0 depuis 03:12 · CPU 4% / supervision: tout est vert
On regarde Pas la machine, mais le chemin : d'où partent vos commandes, vos appels ou factures, par où ils passent, ce qui prouve qu'ils arrivent. Le flux lui-même, pas la machine : d'où partent les commandes, les CDR ou les factures, par où ils passent, ce qui atteste leur arrivée.
On trouve souvent Un certificat de sécurité expiré chez un partenaire, des demandes qui s'empilent en silence, un service qui dit « OK » sans rien envoyer, un décalage horaire. Rien ne se voit sur la machine. Un certificat expiré chez un partenaire, une file qui déborde en silence, une API qui répond 200 avec un corps vide, un fuseau horaire. Des pannes invisibles pour une supervision système.
On fait Des contrôles sur l'activité (« combien de commandes dans la dernière heure ? »), des alertes qui parlent votre langue, et au passage on accélère ce qui traîne. Des sondes métier (« combien de commandes dans la dernière heure ? »), des alertes qui parlent le langage du métier, et on accélère les passages lents dans la foulée.
Résultat 1 212 commandes/h, 0,8 s par commande, alerte si ça chute de moitié. Vous le saurez avant vos clients. Flux commandes : 1 212/h, latence 0,8 s, alerte sous -50 %. Vous le saurez avant vos clients.
Service informatique, prestataire et développeurs se renvoient la balle La DSI, l'infogérant et les développeurs se renvoient la balle
Ce que vous voyez Trois semaines, quatre intervenants, zéro décision. / « C'est le serveur. » « Non, le logiciel. » ticket #4812 : 3 semaines, 4 intervenants, 0 décision / « c'est l'infra » / « c'est le code »
On regarde L'historique des deux côtés, le contrat du prestataire, ce que chacun attend de l'autre. Souvent, personne ne regarde à la fois le logiciel et les serveurs. Les journaux des deux côtés, le contrat d'infogérance, et ce que chacun attend réellement de l'autre. Souvent, personne ne lit à la fois le code et l'infra.
On trouve souvent Pas les mêmes mots : une panne à réparer pour l'un, une amélioration pour l'autre. Des responsabilités floues. Et un problème technique assez petit une fois posé à plat. Un vocabulaire différent (un « incident » pour l'un, une « évolution » pour l'autre), des responsabilités floues, et un problème technique assez petit une fois posé à plat.
On fait On réunit tout le monde, on tranche avec des faits, on écrit qui fait quoi, on suit jusqu'à la mise en service. Vos serveurs gérés par nous ou par un autre, ça ne change rien. On cadre, on arbitre avec des faits, on écrit la procédure, on tient le fil jusqu'à la mise en production. En infogérance chez nous ou chez un tiers, ça ne change rien.
Résultat Décidé en 2 jours, en service en 9, un seul interlocuteur. Chacun reprend son métier. Décision J+2, mise en prod J+9, un seul interlocuteur. Chacun reprend son métier.
Une armoire de serveurs à reprendre avant qu'elle ne lâche Une baie à reprendre avant qu'elle ne lâche
Ce que vous voyez Câbles sans étiquette, une seule arrivée de courant. / Fibres optiques en vrac, trois disques durs prêts à lâcher. câblage sans étiquette · 2 PDU sur la même phase / tiroir FO sans lovage · smartd: 3 disques en pré-panne
On regarde Ce qu'il y a vraiment dans l'armoire : courant, ventilation, trajet des câbles, état des disques durs et du logiciel interne qui les pilote. Ce qu'il y a vraiment dans la baie : alimentation, ventilation, chemins de fibre et de cuivre, état SMART des disques, firmwares des contrôleurs.
On trouve souvent Des liaisons vitales sans vrai câble de secours, des cordons trop courts, des fibres optiques pincées. Des disques durs pas vérifiés depuis des années. Des liens critiques sans redondance réelle, des jarretières trop courtes, des fibres pincées, des disques dont personne n'a lu les compteurs depuis des années.
On fait Plan de l'armoire, recâblage propre et étiqueté. Fibres optiques raccordées à neuf, rangées et testées. Disques durs et blocs d'alimentation changés machine éteinte, avec photos. Plan de baie, recâblage propre et étiqueté, fibres re-soudées et lovées dans les tiroirs, mesures OTDR, disques et alimentations remplacés à froid, documentation photo.
Résultat Plan à jour, 2 arrivées de courant, 0 câble sans étiquette. Le prochain intervenant s'y retrouve en cinq minutes. Baie documentée, PDU A/B, 0 lien sans étiquette. Le prochain intervenant s'y retrouve en cinq minutes.
Vous voulez de l'IA, mais branchée sur vos données et sous contrôle
Ce que vous voyez Troisième essai abandonné, des mots de passe qui traînent. / « On ne sait pas ce que ça coûte ni ce que ça voit. » PoC n° 3 abandonné · clés d'API dans un script / « on ne sait pas ce que ça coûte ni ce que ça voit »
On regarde Quelles données, où elles sont, qui a le droit de les voir, ce que l'assistant doit savoir faire. Et ce qu'il ne doit surtout pas faire. Quelles données, où elles vivent, qui a le droit de les voir, ce que l'assistant doit savoir faire — et ce qu'il ne doit surtout pas faire.
On trouve souvent Des essais qui restent des essais, une IA qui voit plus qu'elle ne devrait, une facture que personne ne regarde. Et rien ne la relie aux outils que l'équipe utilise vraiment. Des maquettes qui n'atteignent jamais la production, des accès trop larges, aucun suivi des coûts, et pas de pont entre le modèle et les outils que l'équipe utilise vraiment.
On fait Un assistant branché sur vos outils, qui ne voit que ce qu'on lui permet. Hébergé chez vous ou chez un prestataire de confiance, selon la sensibilité des données. Testé sur vos vrais cas, coûts suivis comme le reste. Un serveur MCP sur vos API, des agents aux droits limités, un modèle hébergé ou on-prem selon la sensibilité, une évaluation sur vos vrais cas, et la supervision des coûts comme pour n'importe quel service.
Résultat Branché sur les demandes d'aide et la base de données : 1 200 questions/jour, coût suivi au jour. De l'IA qui travaille, pas une démo. Assistant branché sur les tickets et la base : 1 200 requêtes/j, coût suivi au jour. De l'IA qui travaille, pas une démo.
Un serveur à mettre à jour après six ans, sans arrêter l'activité Un serveur de prod à monter d'Ubuntu 18 à 24, sans fenêtre de coupure
Ce que vous voyez Plus aucune mise à jour, trois grandes versions de retard. / « On n'ose plus y toucher. » Ubuntu 18.04 EOL · PHP 7.2 · MySQL 5.7 · 3 LTS d'écart / « on n'ose plus y toucher »
On regarde Ce qui est vraiment installé : programmes, tâches automatiques, composants figés, installations à la main. Ce qui est sauvegardé et réellement récupérable, et jusqu'où votre logiciel peut suivre. Tout ce qui tourne vraiment : services, crons, ports, dépendances figées, paquets installés à la main, ce qui est sauvegardé et réellement restaurable, et ce que le code supporte.
On trouve souvent Des mises à jour introuvables, un composant bloqué tant qu'on ne touche pas au logiciel, des programmes d'un autre âge. Une sauvegarde jamais testée, aucune trace de qui a installé quoi. Des dépôts tiers morts, un PHP qu'on ne peut pas monter sans toucher au code, des scripts en Python 2, un MySQL dont le dump n'a jamais été rejoué, et aucune trace de qui a installé quoi.
On fait On répète la mise à jour sur une copie de la machine, version par version, ou on bascule sur un serveur neuf avec vos données. On met votre logiciel à niveau avec ceux qui le développent, on teste chaque programme, on écrit la marche à suivre et comment revenir en arrière. Le jour J : coupure courte, dernière sauvegarde, mise à jour, vérifications, et on reste jusqu'au lendemain matin. On rejoue la montée sur un clone de la machine, LTS par LTS (18 → 20 → 22 → 24) ou par bascule vers une machine neuve avec migration des données ; on aligne le code avec les développeurs (PHP 7.2 → 8.3), on teste chaque service, on écrit la procédure et le plan de retour. Le jour J : fenêtre courte, sauvegarde froide, exécution, contrôles, et on reste jusqu'au lendemain matin.
Résultat Tout à jour : coupure de 25 minutes, 0 demande d'aide le lendemain. Et une machine qu'on peut à nouveau mettre à jour chaque mois. Ubuntu 24.04, PHP 8.3, MySQL 8.0 — coupure 25 min, 0 ticket le lendemain. Et une machine qu'on peut à nouveau mettre à jour chaque mois.