On ne peut pas éviter ce qu'on nomme “failles de sécurité” en informatique, il s'agit d'un problème assez simple et universel, qu'exprime bien la fameuse sentence « la perfection n'est pas de ce monde », et sa version pour notre espèce, « l'erreur est humaine ». En soi ce n'est pas un problème mais une situation, pour espérer atteindre la perfection il faudrait tout savoir de tout partout. Cela dit, localement, pour le sous-système Terre-Lune, on peut envisager dans une sous-partie de ce sous-système et pour un temps limité de mener des projets où les risques d'erreurs sont suffisamment anticipés et des procédures de correction des erreurs suffisamment solides pour aboutir régulièrement, presque systématiquement, au résultat anticipé. Tenant compte qu'un système local de ce genre ne peut pas comporter de processus absolument fiables, on les conçoit nécessairement dans une optique “toutes choses égales par ailleurs” et même les anticipations de corrections d'erreurs tiennent compte de ce que l'on connaît. D'où l'inéluctabilité des “failles de sécurité”.
Qu'est-ce proprement qu'une faille de sécurité ? D'après Wikipédia, qui ne définit pas strictement l'expression mais décrit la chose sur son article sur la ((wpf:Vulnérabilité (informatique)|vulnérabilité informatique]], c'est
la conséquence de faiblesses dans la conception, la mise en œuvre ou l'utilisation d'un composant matériel ou logiciel du système, mais il s'agit souvent d'anomalies logicielles liées à des erreurs de programmation ou à de mauvaises pratiques.
Il s'agit comme souvent en ces questions d'une approche rationalisante qui considère a priori qu'on peut, disons, créer un objet non vulnérable, non faillible, une réflexion tout-à-fait du genre “toutes choses égales”, qui postule implicitement un créateur omniscient capable de tout anticiper sur une question donnée, ainsi qu'une immuabilité des choses. Or, si un certain nombre de failles de sécurité ont bien pour origine une conception faible, ou une réalisation ou une utilisation incertaine – soit dit en passant, les passages successifs « faiblesses dans [...] la mise en œuvre ou l'utilisation » et « anomalies logicielles liées à des erreurs de programmation ou à de mauvaises pratiques » disent à-peu-près la même chose... Or, beaucoup de ces vulnérabilités sont imprévisibles au moment de la conception du logiciel ou matériel. Je pense entre autres aux deux failles de sécurité à l'origine de la rédaction de « Un spectre hante les nuages », dont je ne me rappelle plus trop le nom, l'une doit être “Spectre”, l'autre je ne sais plus, qui n'en sont devenues que bien après la conception du matériel qui s'est révélé faillible : les concepteurs du matériel ont du trancher entre plus de sécurité ou plus d'efficacité et ont opté pour plus d'efficacité, parce qu'à l'époque, disons, on accédait au matériel concerné “par le haut”, par le biais du système d'exploitation, lui-même sécurisé, alors que l'évolution ultérieure des processeurs a permis d'y accéder “par le bas”, directement par le matériel, sans devoir en passer par le logiciel. D'évidence, les concepteurs de 2001 ou 2002 ne pouvaient d'aucune manière se prémunir contre un problème que rien ne permettait d'anticiper – pour prendre un exemple dans d'autres domaines, un concepteur d'avion de 1937 ne peut en aucun cas prévoir des sécurités valables pour des avions à réaction, c'est hors de son univers conceptuel, et ce ne sera que quelques années après qu'on s'apercevra qu'une structure conçue pour des aéroplanes propulsés par des hélices n'est pas valable pour d'autres modes de propulsion.
Rien n'est jamais égal dans un contexte en constante évolution.