bp8rt

C'est un choix américano-allemand. Les premiers par habitude et pour foutre le bordel en europe (rappelez-vous les guerres de Yougoslavie ); Les second pour étendre leur zone d'influence et de main d'oeuvre quasi gratuite.

Non. On possède quelques échantillons même pas suffisants pour couvrir les besoins de défense de quelques sites stratégique. Défendre efficacement un territoire relativement petit nécessiterait plus de système. Apporter une couverture simultanée de nos opexs augmente le besoin. Enfin, quel est la capacité à durer de ses systèmes ? Maintenir la veille pendant une année par exemple.

L'idée est de déporter toutes ces fonctions dans des PC volants. La question est ensuite de savoir si ce découpage a un sens. Les PC devront être là pour permettre le fonctionnement du système et son autodéfense. Quid d'une interdiction de vol suite à un accident ? A la rigueur, un segment spatial fortement redondé pourrait être une solution. Ensuite on a de toute façon pas les moyens de commander ne serait ce que le quart de ces missiles pour l'intégralité de la flotte. Alors tout concentrer sur la même barge ! Je verrai plus de logique a avoir un (ou deux à trois pour la redondance) systèmes de détection / commandement pilotant une dizaine de porteurs de missiles. Séparer les uns des autres rend les porteurs missiles plus discret (pas de radar) Comme cela en cas d'attaque, il n'y a pas de cible évidente. Faire sauter un porteur de missile n’empêche pas la poursuite de la mission, idem pour les systèmes de détection/commandement. Mais au final on est très prêt de la solution actuelle (au détail prêt du nombre d'unités). Et le porteur regroupant missile, détection, commandement donne le plus de souplesse en composition de force.

Double dérive, cela veut dire plus de traînée. Dégrader les perfs pour des raisons marketting ! Sur un avion de combat ! Je veux bien que le marketting est roi, mais faut pas pousser.

S'il y a des Rafales en 2050 dans l'AA, ils auront été produit en 2025.

L'idée d'une politique étrangère commune est irréaliste l'essentiel des pays européens étant de fait des territoires sans autonomie diplomatique vis à vis des états-unis. Et malheureusement la France rentre dans le rang.

On peut connaître l'argumentation ? Parce qu'autant sur le deuxième point (les moyens financiers) on peut comprendre et ma question n'était là que pour appuyer sur cette impasse. Mais sur le premier point, pourquoi le consortium n'aurait il pas le droit de vouloir améliorer son avion pour en faire un moyen utile pour les forces aériennes clientes ?

L'objectif exprimé est somme toute d'arriver aux mêmes capacités que le Rafale. C'est un objectif louable, mais à quels coûts cet avion, déjà cher, arrivera-t'il à égaler le Rafale ? Les partenaires du programme ont-ils les moyens d'atteindre cet objectif ?

Le besoin, c'est en Guyane ; un tirant d'eau réduit. Pour la remontée de fleuve ?

Les deux partis politiques de gouvernements prennent d'autant plus des postures d'opposition totale qu'ils sont d'accord sur à peu près tout. Pour avoir des politiques qui acceptent débats et compromis, il faut des programmes et des idéologies qui diffèrent car dans ce cas, on a pas besoin de prendre des postures !

Les populations aisées ont un meilleur accès à l'information et une capacité, acquise par l'éducation, à arbitrer leurs envies face à des critères notamment de santé. Par ailleurs, l'accès à la santé est de plus en plus compromis pour les pauvres dans de nombreux pays qualifiés de développés.

Il ne faut pas être naïf ; de très nombreuses ONG ne sont que des outils de propagande et de pression politique au service d'états, de multinationales ou autres groupes d’intérêts.

Pour moi, il était inaccessible entre 17h00 t 19h55 Probablement à cause de la Rafale de post.

Non, Roger devait développer une fonction faisant papa-maman en recevant en entrée une bardée de paramètres et d'objets dans un état clairement définie et retourner un ou plusieurs résultats avec des modifications clairement déterminées des objets auxquels il avait accès. Tes tests, vérifient ce respect des spécifications. Tant qu"elles ne changent pas, c'est à Robert de faire le taf pour que sa fonction respectent les specs. C'est en tous les cas le cas pour les tests en boite noire (je ne connais pas l’implémentation, je vérifie que sur les paramètres 1 et 1 la fonction addition renvoie 2 (quelque soit l'algo utilisé). Pour les tests en boite blanche (en connaissant l'implémentation, Robert est le mieux à même de les réaliser (c'est lui qui connaît le code) sauf effort énormes pour tester tous les cas de figures qui indépendamment de l'algo peuvent créer un cas spécifique , une branche dans le code... Quasiment impossible à faire. C'est aux codeurs de respecter les spec et les contraintes explicitées dans les spécifications.

Je n'ai aucun détail sur l'affaire, mais je ne vois pas pourquoi nous nous brouillerions pour cela. L'Indonésie est un pays avec ses lois, sa justice, et nos ressortissants sont tenus de les respecter quand ils sont la bas. Et ce même si je suis totalement opposé à la peine de mort.

C'est le minimum dans le dév aujourd'hui ! Avec aussi beaucoup de problématique de gestion de configuration.

Pour le codage, ça ne se passe pas comme ça. Et vu que manifestement ça intéresse certains. Tout d'abord à partir des docs de spécification fonctionnelle tu fais une spécification technique. Grosso modo tu décrit l'organisation de ton module en fonction de haut niveau, puis de moyen niveau... jusqu'à arriver à des fonctions vraiment simple. Pour chacune de ces fonctions, tu va spécifier ses paramètres et valeurs de retour, les objets auxquelles elle accède, les modifications qu'elle leur fait subir... En bref les interfaces de tous les composants sont explicitées et l'algo de chaque fonction/composant. Les structures de données transverse sont définie... Ensuite, une fois munie de la spécification complète de la petite fonction que tu dois développer, tu va tout d'abord coder les tests. Puis ensuite la fonction. C'est en tout les cas une méthodologie classique. Attention, coder les tests, cela veut dire créer des doublures des objets accédés / modifiés, spécifier comment ils doivent être accédé, dans quel ordre... C'est en soi un vrai développement. Rien à voir avec la sanction du genre "test le code de Robert". Coder du test est souvent plus complexe que coder le produit final. Ça peut tourner au petit défi intellectuel. De toute façon du code développé sans penser aux test unitaires est quasi intestable sauf à tout reprendre (décomposition, modularisation...). Intellectuellement, il y a un aller et retour entre les deux activités. Pour ma part, je préfère alterner entre codage de quelques lignes (un dizaine à tout casser) et codage des tests de ces lignes nouvelles. Ce qui rend le test ingrat dans le développement de logiciel sans enjeu de fiabilité important, c'est que c'est la dernière roue du carrosse. Si sur ton projet, tu édictes des règles claire dans lesquelles tu valorises l'activité de test, ça peut marcher. Et ça fait gagner tellement de temps ensuite lors de l'intégration ! Ensuite, les outillages permettent de vérifier la couverture de test. Il y a même des outils qui te colorie le code : - vert : intégralement exécuté lors des tests; - orange : partiellement testé (cas d'un if complexe ou tu n'as pas eu a exécuté toutes les conditions ; par ex : if (a & b)... Si a est faux, b n'est pas forcément évalué) - rouge : pas testé. En info classique avoir une couverture de 60% c'est peu fréquent. 100% ça coûte très cher !

Toujours sur le sujet du code, si on applique les paradigmes actuels du développement logiciel pour chaque fonction tu dois écrire une batterie de test unitaire te permettant d'affirmer que : - tout le code a été exécuté (on passe par toutes les alternatives de test et tous les cas d'exception/traitement d'erreur); - les limites de chaque boucle sont elles aussi testées; - les plages de valeur significative de chaque paramètre en entrée de la fonction sont essayées ainsi que toute leurs combinaisons (typiquement, 0 est une valeur particulière pour un paramètre numérique soit pour les divisions, soit pour le dimensionnement de tableau). Tu as facilement dix fois plus de lignes de code de test que de code utile. Ce code de test devant être tout aussi fiable (par contre son efficacité est moins importante). Et cela c'est pour le test unitaire des fonctions. Ensuite, il y a les tests d'intégration, les test fonctionnels... Écrire les cahiers de tests est un projet en soi. Et pas le plus facile ! Tous ces tests doivent être exécutés à chaque changement dans le code. Cela implique la mise en œuvre d'automates de test et l'analyse des résultats. De la même façon, la qualité du code sera analysée par des outils dédiés (Sonar, Coverity...). Lesquels mettront en évidence des failles étant passé au travers des étapes précédentes, mais aussi le dépassement de limites issue de bonne pratiques (fonction trop longue, nombre d'alternatives trop importantes...) Et du coup, il faudra refactorer le code pour respecter ces métriques. Et on doit du coup reprendre les test unitaires, d'intégration... Une fois le code réalisé et la version n raisonnablement au point, on fera des tests de métrologie pour vérifier que les perfs attendues sont bien au rendez-vous. Et là, on constatera que la fonction lambda prend dix fois le temps qu'on veut lui accorder, que la consommation mémoire est trop importante... Donc on cherchera des solutions qui passeront par des optimisations du code, des changements d’algorithme... Et on repart pour un tour, codage, test unitaire, test d'intégration, test fonctionnels... Sur le codage proprement dit, chaque variable doit être soigneusement étudiée : quel est le bon type à utiliser, quels sont les plages de valeur possible (avec tous les problèmes de débordement lors des calculs), quelle valeur initiale lui donner... Les algorithmes doivent être soigneusement étudié aussi. Leur efficacité est elle constante ou dépendante des valeurs à traiter. Un exemple basique, de nombreux algorithme de tri voient leur efficacité compromise si les données sont déjà triées par exemple en ordre inverse. On sera donc amener à choisir l'algo en fonction de la connaissance des données ce qui peut nécessiter des études sur celles ci. Un développement sur ce genre de logiciel va t'amener à gérer de multiples versions logicielles. On rentre dans toute la problématique de gestion de configuration avec les soucis associés. On a une vision faussé de toute cette complexité car sur la plupart des projets informatiques, l'essentiel est d'être prêt pour hier avec quelque chose qui réalise grosso modo le besoin. En cas de plantage, on contournera le problème puis on corrigera pour la version suivante. Sur un avion, le plantage sera peut être rédhibitoire (idem sur un métro, une fusée, un satellite) : A cause d'un "bug", la fusée est sortie de sa trajectoire et a du être détruit ainsi que sa charge utile... C'est sur que c'est plus grave qu'une commande loupée parce que dans certains cas, le processus d'enregistrement du panier d'achat se gamelle. Donc là, on voit bien que l'écriture de code "utile" est une toute petite partie du problème. Et que ça n'a rien à voir avec le programme réalisé dans une soirée geek avec bière et pizza. J'ai oublié, le client qui invariablement viendra vous voir à peu près au milieu du dév pour dire que "au fait, faudra aussi faire ..." Et vlan, on reprend du début, on cherche comment ne pas tout casser et jeter... (exemple en aéro militaire, les biplaces d’entraînement qui deviennent biplace de combat et ou le poste arrière passe d'instructeur avec affichage identique au poste avant, à navigateur-bombardier qui a des besoins bien spécifiques). Donc les 250 lignes par ans, c'est très crédible.

250 lignes de code du logiciel réellement embarqué. Et des dizaines de milliers de lignes de code de tests, de simulations… Sans compter les contraintes sur le code : utilisation de languages tres rigoureux, donc largement plus difficile d'utilisation. Analyse statique et dynamique du code. Traitement de tous les cas d'exception… Çà n'a rien à voir avec la programmation traditionnelle. Sans compter les contraites d'efficacité !

C'est sur que les relations c'est important pour le dressement reproductif :)

Pour les communications cryptés, en bref les seuls intéressantes dans une optique anti terroriste sérieuse, on a le choix entre acheter des super ordinateurs en quantité défiant l'imagination pour tenter de décrypter les messages, ou bien de les stocker en attendant : - les progrès de la cryptanalyse et ou des ordinateurs, - la découverte d'une faille algorithmique ou d'un bug simplifiant de décryptage - la découverte de la clef de dé"chiffrement par un biais ou un autre permettant de déchiffrer les messages stockés. En pratique, le premier choix est financièrement inatteignable à la France (pour ce qu'on sait la NSA n'y arrive pas systématiquement non plus). Le deuxième s'impose donc. En pratique on tente les deux solutions. le décryptage sur les algo les plus faibles ou ceux pour lesquels on connaît des failles simplifiant le problème. Le stockage pour ceux qui mettrait des années à décrypter. Ajoutons pour la NSA, la création de faille dans les logiciels qui posent problème (via des contributions pour les logiciels libre et par divers biais dont l'infiltration dans les référentiels de sources pour le logiciel en source fermé) ou en faisant fermer les projets qui dérangent. Notons qu'avec les progrès des GPU (le circuit graphique de votre PC haut de gamme) par exemple, le temps de décryptage peut être plus long que le temps d'attente d'un GPU suffisamment performant pour décrypter en temps raisonnable.

Les déboires de l'Eurofighter ont bien montré la valeur d'un personnel compétent et bien formé. Pas sur que Dassault ait envie de galérer à retrouver et reformer ce personnel à chaque à coup de production.

Alors qu'en enfer, les étudiants sont nourris et logés !

Tant qu'il n'est pas nécessaire de réindustrialiser pour augmenter la production, c'est rentable et ça fait diminuer les coûts. Par contre dés qu'il faut acquérir de nouveaux moyens de production, c'est plus compliqué car il faut amortir l'usage de ces nouveaux moyens sur la quantité supplémentaire produite. Ce qui nécessite de la connaître ! De plus, on ne peut pas forcément dimensionner au plus juste. Si on a besoin d'une machine quelconque pour faire une pièce, on n'obtient l'optimum qu'à partir du moment ou on produit suffisamment de pièces pour occuper la machine à temps plein. Comme il y a une multitude de pièces et d'équipements avec des outils de production encore plus nombreux, il faut trouver l'optimum sur l'ensemble du cycle de production. Sans oublier le personnel pour faire fonctionner tout cela.

Un gros avantage pour l'armée de l'air et pour la marine, c'est de maintenir ouverte la chaîne de production Rafale. Cela permet d'envisager d'en acheter d'autres. dans cinq ou dix ans. Et puis, si il y a finalement une grosse commande ou plusieurs petites, cela fera légèrement baisser les coûts. Ça pourrait même finir par intéresser Dassault, Thalès, Safran & cies.