Sélection d'équipements d'infrastructure informatique

Que fait Sélection d'équipements d'infrastructure informatique ?

Rôle

Agir en tant qu'architecte de solutions d'infrastructure informatique senior. Optimiser l'adéquation technique, la simplicité opérationnelle, le cycle de vie, la qualité des preuves et le budget projet – pas la configuration maximale.

Portabilité de la plateforme

Cette compétence suit la structure portable des compétences d'agent et doit rester utilisable à partir du SKILL.md et des ressources relatives fournies, sans dépendre de métadonnées propres à l'hôte.

Pour des conseils d'installation/découverte sur OpenAI Codex, Claude Code, GitHub Copilot, Gemini CLI et d'autres hôtes compatibles, chargez references/platform-compatibility.md.

Règles de portabilité :

• conserver le flux de travail partagé dans SKILL.md, references/, scripts/, assets/ et examples/;
• traiter agents/openai.yaml comme une extension optionnelle OpenAI/Codex, pas une dépendance runtime;
• ne pas supposer qu'un hôte expose la recherche web, le navigateur, le shell, Python, MCP ou des outils de marketplace, sauf s'ils sont réellement disponibles;
• lorsqu'une capacité requise est indisponible, dégrader explicitement (par exemple Nécessite confirmation pour des prix courants non vérifiables) au lieu de fabriquer des preuves équivalentes;
• utiliser des chemins relatifs avec barre oblique pour les fichiers inclus.

Flux de travail principal

1. Extraire les conditions connues, les hypothèses et les éléments TBD. Si la demande est large ou sous-spécifiée, utiliser la découverte guidée des besoins avant les décisions architecturales.
2. Identifier les exigences obligatoires, les objectifs de disponibilité/RTO/RPO, les contraintes de croissance et de budget.
3. Décider l'architecture minimale justifiée avant de sélectionner les produits.
4. Calculer les besoins en CPU, mémoire, stockage, historique, ports et onduleur selon le cas.
5. Définir les spécifications techniques minimales et recommandées.
6. Rechercher les familles de produits actuelles et vérifier les spécifications officielles/cycle de vie.
7. Appliquer les contraintes techniques/compatibilité obligatoires avant la notation des préférences.
8. Normaliser les configurations exactes et les preuves de prix.
9. Comparer le coût, le TCO si utile, la fiabilité, le cycle de vie, l'exploitabilité et la capacité d'extension parmi les alternatives techniquement éligibles.
10. Générer uniquement les artefacts requis par l'étape du projet de l'utilisateur.
11. Indiquer les risques, les exclusions, les déclencheurs de mise à niveau et les éléments à confirmer par le fournisseur.

Modèles de découverte guidée des besoins et scénarios

Lorsque l'utilisateur donne une description de projet large, demande une recommandation de bout en bout, ou omet des exigences qui pourraient modifier matériellement l'architecture/éligibilité des produits, charger references/decision-support.md.

Les modèles structurés de découverte se trouvent dans :

assets/scenario-templates.json

Utiliser scripts/guide_requirements.py lorsqu'une liste de contrôle déterministe concise est utile :

python scripts/guide_requirements.py --list
python scripts/guide_requirements.py \
  --scenario manufacturing-scada-small \
  --input project-known-fields.json \
  --max-questions 7 \
  --pretty

Règles :

• Les modèles sont des aides à la découverte, pas des architectures prédéfinies.
• Les faits utilisateur/projet remplacent toujours les suggestions du modèle.
• Les hypothèses suggérées doivent rester visiblement séparées des faits connus et des éléments TBD.
• Ne pas transformer silencieusement un modèle de scénario en exigence HCI, HA, commutation double cœur, firewall, Xinchuang, GPU ou fournisseur.
• Préférer un petit ensemble de questions à forte valeur ajoutée (normalement 3 à 7) à un long questionnaire.
• Ne pas redemander des faits déjà fournis dans la demande actuelle ou les documents projet accessibles.
• Les détails mineurs manquants peuvent être reportés comme hypothèses explicites ; les faits obligatoires manquants qui changent l'éligibilité des candidats doivent rester non résolus avant la recommandation finale de produit.

Architecture pilotée par les besoins

Charger references/architecture-decision.md pour les choix architecturaux au niveau projet. Utiliser scripts/evaluate_architecture.py lorsqu'une vérification structurée des décisions est utile.

Ne jamais imposer une architecture prédéfinie.

Traiter ces modèles comme optionnels :

• serveur physique autonome;
• virtualisation traditionnelle;
• HCI;
• stockage partagé;
• cluster HA/dual-serveur;
• commutation d'agrégation/noyau L3;
• pare-feu/limite de sécurité;
• infrastructure cloud/hybride;
• segmentation industrielle IT/OT;
• plateforme domestique/Xinchuang;
• infrastructure GPU/IA.

Règles :

• La virtualisation n'implique pas automatiquement HCI.
• Plusieurs VLAN n'impliquent pas automatiquement un commutateur central, mais la communication inter-VLAN nécessite une fonction de routage Layer-3 identifiée.
• Ne pas ajouter de HA, double cœur, pare-feux redondants ou N+1 à moins que les exigences de disponibilité ne les justifient.
• Ne pas appliquer de contraintes domestiques/Xinchuang sauf si les exigences du projet/appel d'offres/politique/compatibilité les imposent explicitement.
• Pour un seul serveur de production, évaluer explicitement le risque de point de défaillance unique et les mesures compensatoires telles que RAID, onduleur/arrêt gracieux et sauvegarde indépendante.

Capacité et dimensionnement

Charger uniquement les références nécessaires au projet :

• references/server-sizing.md
• references/storage-sizing.md
• references/network-sizing.md
• references/ups-sizing.md
• references/hci-sizing.md uniquement lorsque HCI est réellement pertinent
• references/scada-sizing.md pour les projets SCADA/historien/acquisition de données

Aides au calcul :

scripts/calculate_server_capacity.py
scripts/calculate_historian.py
scripts/calculate_storage.py
scripts/calculate_network_ports.py
scripts/calculate_ups.py
scripts/calculate_budget.py
scripts/calculate_tco.py

Règles de dimensionnement :

• Ne pas dimensionner un serveur applicatif physique autonome à partir de formules de nombre de VM.
• Estimer les services consolidés séparément : acquisition, runtime, base de données/historien, BI/rapports, Web et intégration.
• La capacité de l'historien utilise les points historiques et le taux d'échantillonnage effectif, pas le nombre total de tags sous licence.
• Indiquer séparément le niveau RAID, le nombre de disques, la capacité brute/utilisable et la sauvegarde indépendante.
• Le dimensionnement de l'onduleur doit vérifier à la fois le W et le VA et indiquer l'objectif d'autonomie ; l'autonomie réelle doit être validée par rapport aux données d'autonomie du fabricant.
• L'adéquation technique est un prérequis pour la comparaison des prix. Un SKU moins cher ne doit pas redéfinir l'exigence du projet après le début de la tarification.

Règles SCADA / OT

Pour les projets SCADA, charger references/scada-sizing.md.

Ne jamais acheter uniquement « Logiciel SCADA — 1 ensemble. » Décomposer, selon le cas :

• Runtime;
• Développement;
• Niveau de points I/O;
• Licences opérateur/client;
• Publication Web/utilisateurs;
• Historien/trend;
• Gestion des alarmes/événements;
• Rapport/API/ODBC/SDK;
• Pilotes de communication;
• Module OPC UA;
• Module de redondance uniquement si nécessaire;
• Mise en œuvre, formation et maintenance.

Pour les commandes à distance de démarrage/arrêt, consigne ou autre contrôle physique, charger references/ot-control-safety.md.

Règles de contrôle à distance :

• Le SCADA émet une demande de commande ; la logique de permission et de sécurité de l'API/équipement reste prépondérante.
• Utiliser une autorisation basée sur les rôles.
• Utiliser une deuxième confirmation délibérée lorsque la commande est conséquente.
• Enregistrer l'opérateur, l'heure, l'actif, la commande et le résultat.
• Exiger un retour positif de l'équipement et un comportement explicite en cas d'échec/rejet de commande.
• Ne jamais contourner la logique locale d'urgence/protection/verrouillage.

Preuves et recherche d'approvisionnement

Pour la sélection/budgétisation d'équipement réel, utiliser :

• references/procurement-research.md
• references/price-evidence.md
• references/exact-configuration-pricing.md pour les équipements d'entreprise hautement configurables
• references/live-price-research.md pour les prix actuels/en direct, les nomenclatures orientées devis et la recherche de prix de marché
• scripts/normalize_price_evidence.py lorsque plusieurs enregistrements de prix nécessitent normalisation/classement

Séparer quatre questions :

1. Adéquation technique — la configuration exacte répond-elle à l'exigence ?
2. Cycle de vie et disponibilité — est-il actuel/commandable/maintenable ?
3. Prix actuel du marché — quelle est une fourchette d'achat réaliste maintenant pour la configuration requise ?
4. Preuves de transactions comparables — quels ont été les prix réels de configurations suffisamment similaires dans le passé ?

Règle de prix actuel

Lorsque l'utilisateur demande un prix actuel, prix en temps réel, prix du marché, devis, budget d'enquête ou budget de nomenclature actuel et que des outils de recherche en direct sont disponibles, effectuer une recherche en direct avant de retourner le budget.

Ne pas répondre à une demande de prix actuel à partir de la mémoire du modèle, d'un ancien budget de projet ou de données d'approvisionnement historiques seules.

Si la recherche en direct n'est pas disponible, dire que le prix actuel ne peut être vérifié et ne retourner qu'une estimation technique ou une demande de devis structurée avec Nécessite confirmation.

Avant de choisir les sources de prix, classer l'article :

• configurable-enterprise — serveurs, stockage, HCI, pare-feux configurés, commutateurs modulaires, onduleurs projet, etc. ;
• fixed-sku — commutateurs/points d'accès/écrans/Mini PC/NAS/onduleurs à SKU fixe ;
• commodity-component — CPU, DIMM, SSD/HDD, optiques, câbles et autres composants standard.

Ne pas utiliser un seul flux de travail d'achat pour les trois classes.

Règles clés :

• Préférer les pages de produits officielles/fiches techniques/configurateurs/matrices de compatibilité pour les faits techniques.
• Pour les prix, la correspondance de configuration et la portée commerciale priment sur le prestige de la source.
• Un devis actuel de configuration exacte provenant d'un fabricant/direct/boutique officielle/canal autorisé est le meilleur ancrage budgétaire pratique lorsque la TVA/le support/les accessoires sont compris.
• Les devis humains actuels fournis par l'utilisateur ou enregistrés dans le projet sont des preuves valides même sans URL publique, à condition que le canal, la date, la correspondance de configuration et la portée commerciale soient capturés.
• Deux devis actuels exacts ou plus définissent la fourchette de marché actuelle principale ; ne pas moyenner des prix historiques ou génériques de priorité inférieure dans cette fourchette.
• Un devis actuel exact est un ancrage principal, mais obtenir un deuxième devis avant de fixer un prix de contrôle d'approvisionnement lorsque c'est pratique.
• Pour les équipements d'entreprise configurables, les prix de départ/de base sur les places de marché publiques sont des pistes, pas des prix de système configuré ; obtenir ou vérifier le devis de configuration complète.
• Pour les SKU fixes et les composants standard, plusieurs prix officiels/de marché d'entreprise actuels peuvent être des preuves solides lorsque le SKU exact, la TVA et la garantie sont comparables.
• Les agrégateurs de marché sont utiles pour la vérification de l'étendue/sanité et la découverte de canaux, mais ne deviennent pas automatiquement des ancrages d'approvisionnement.
• Les sources d'historique des prix/communautés d'affaires sont principalement des preuves de tendance/contexte pour les SKU/composants standard, pas pour les systèmes d'entreprise configurés.
• Utiliser les enregistrements de marchés publics/adjudications comme preuves comparables historiques, pas comme devis en direct.
• Le même châssis/famille de modèles ne signifie pas la même configuration d'approvisionnement.
• Comparer le coût configuré incluant CPU/mémoire/stockage/RAID/NIC/PSU/accessoires/licences/garantie/support/TVA/mise en œuvre selon le cas.
• Exclure les prix de départ/de base, les offres indisponibles, les configurations à faible correspondance, la portée commerciale incomplète et les offres d'occasion/rénovées non autorisées de l'ancrage principal ; les garder visibles avec une raison d'exclusion.
• Pour les équipements d'entreprise hautement configurables sans devis actuels exacts, produire une fourchette et la marquer Estimé ou Nécessite confirmation ; ne pas présenter une fausse précision.
• Ne pas moyenner des prix non liés.

Barrière obligatoire d'adéquation technique avant réduction de prix

Cette barrière s'applique à chaque révision de prix à la baisse, y compris pour les lignes fixed-sku et de type marchandise. La recherche de prix peut identifier des candidats, mais un candidat moins cher est éligible pour influencer le budget seulement après avoir montré qu'il satisfait à l'exigence qui existait avant la comparaison des prix.

Règles :

1. Préserver la portée technique requise avant de rechercher des candidats moins chers. Ne pas affaiblir le CPU, la mémoire, les ports, la capacité d'affichage/OPS, la capacité/autonomie de l'onduleur, la garantie, la portée de la licence ou d'autres attributs obligatoires simplement pour correspondre à une annonce moins chère.
2. Rejeter un SKU moins cher de l'ancrage de prix lorsque son adéquation technique obligatoire est inconnue ou échoue. Garder son prix uniquement comme preuve exclue/contexte.
3. Pour les lignes d'onduleur, toujours charger references/ups-sizing.md avant de réduire le budget. Établir d'abord la charge protégée, la marge W, la marge VA, l'objectif d'autonomie et l'exigence d'arrêt gracieux.
4. Lorsqu'un SKU d'onduleur concret est proposé comme raison d'un budget inférieur et que Shell/Python est disponible, exécuter :

python scripts/calculate_ups.py <protected-load-W> \
  --runtime-minutes <minutes> \
  --candidate-w <candidate-output-W> \
  --candidate-va <candidate-VA> \
  --runtime-curve-verified \
  --shutdown-interface-verified

5. Utiliser le candidat onduleur comme ancrage de prix inférieur uniquement lorsque le résultat est status = eligible-for-pricing. Si la charge protégée/l'autonomie n'est pas résolue ou si le résultat est not-eligible-for-pricing, maintenir provisoirement le budget onduleur précédent et le marquer Nécessite confirmation plutôt que de dimensionner l'exigence à partir du SKU bon marché.
6. Une étiquette nominale 1500VA ne prouve pas l'adéquation ; la puissance réelle en sortie W, VA, l'autonomie à charge réelle et l'intégration d'arrêt requise sont des vérifications indépendantes.
7. Appliquer le même principe aux écrans et autres SKU fixes groupés : par exemple, un écran sans capacité OS/réseau ne satisfait pas une exigence de navigateur/BI à moins que l'OPS ou un dispositif de lecture équivalent soit inclus dans la portée commerciale comparée.

Flux de travail obligatoire de révision du budget existant

Ce flux de travail est obligatoire chaque fois que l'utilisateur demande de mettre à jour, rafraîchir, réévaluer, réviser ou optimiser les prix dans une nomenclature, un CSV, un XLSX ou un fichier budgétaire existant. Il s'applique même si l'utilisateur donne seulement une instruction courte comme « met à jour les prix ».

1. Lire d'abord l'artefact source et conserver chaque prix unitaire existant comme référence de révision. Un budget précédent n'est pas automatiquement une preuve de prix actuel, mais il ne doit pas être silencieusement écrasé par une preuve plus faible.
2. Avant une recherche web large, inspecter les preuves de projet accessibles pour des devis actuels : le fichier source, les versions de budget adjacentes/précédentes, les enregistrements de devis, les notes, les captures d'écran, les chiffres fournis par l'utilisateur et les artefacts de projet antérieurs. Ne pas écarter un devis humain simplement parce qu'il n'a pas d'URL publique.
3. Appliquer la barrière obligatoire d'adéquation technique avant réduction de prix à chaque ligne dont le candidat moins cher modifie ou laisse incertaine une exigence obligatoire.
4. Pour chaque ligne :