Catégories
AF2000

Faille ou porte dérobée : une confusion bien commode

Dans le même temps que Snowden ou l’affaire Gemalto nous révélaient l’emprise de la NSA sur le monde numérique, de nouvelles failles de grande ampleur (Heartbleed, FREAK, POODLE) venaient remettre en cause des briques fondamentales de la cybersécurité.

Porte dérobéeUne faille est, par définition, un vice involontaire de conception. Or dans de nombreuses affaires récentes, il est avéré que la « faille » a été introduite volontairement dans le logiciel incriminé. Cette pratique, porte le nom de « porte dérobée », « backdoor » en anglais. Elle permet à un tiers de contourner les protections d’un logiciel, avec la complicité de l’éditeur.

Une faille peut égratigner une relation de confiance, surtout lorsqu’elle tarde à être corrigée. Elle reste néanmoins une erreur humaine tout à fait normale. Une porte dérobée est bien pire. Elle trahit la malhonnêteté manifeste de l’éditeur, ce qui annihile toute possibilité de confiance, sève de la sécurité. Rien ne prouve qu’une porte dérobée, supprimée avec mille excuses, n’aie pas simplement été cachée ailleurs. D’où l’intérêt pour une entreprise de déclarer comme « faille », toute porte dérobée pas trop flagrante. Une maniére de travestir la malhonnêteté en erreur humaine, ce qui est bien commode.

Les entreprises françaises sont bien peu au fait des dangers des portes dérobées. Elles accordent bien souvent une confiance absolue à des logiciels propriétaires (à « recette » secrète), appartenant à des éditeurs étrangers. Ce qui peut représenter de potentielles fuites de données sensibles vers des pays concurrents.

Catégories
AF2000

Critique de The Code

The Code

Série australienne actuellement en diffusion, The Code base son intrigue sur le thème très porteur du hacking et de la cybercriminalité. Un journaliste et son frère, hacker repenti, enquêtent sur la mort d’une adolescente, liée à un mystérieux camion au chargement top secret. La série tombe, hélas, dans un travers habituel du cinéma : le hacker est présenté comme une sorte de demi-dieu de l’informatique capable de hacker un site top secret en cinq minutes. Rien à voir avec la réalité du hacker, pouvant passer des nuits à la recherche de vulnérabilités le plus souvent inexploitables. La série pèche également en plongeant trop brutalement le spectateur dans l’intrigue, sans aucune introduction.  Dommage car une fois les acteurs en tête, la série est plutôt plaisante à regarder et donne envie de connaître la suite. L’environnement australien dépayse, la réalisation est soignée et les acteurs sont bons.

Catégories
AF2000

Cybersécurité : promouvoir la création française

logo-du-fic-2015Le septième Forum international de la cybersécurité (FIC) vient de se tenir à Lille. Il est à la fois le relais et la sonde de la stratégie française en matière de sécurité des systèmes d’information. Cette manifestation étantétroitement liée à l’État, le discours d’ouverture a porté, sans surprise, sur la lutte contre le “cyberdjihadisme” et le renforcement de la surveillance. Ce discours anxiogène a, hélas, masqué le véritable intérêt du FIC : les dizaines de PME françaises et européennes venues nouer des liens entre elles et présenter leurs innovations. Si beaucoup n’ont fait qu’industrialiser des technologies méconnues venues du monde du logiciel libre, quelques acteurs ont su proposer aux entreprises des services de pointe à forte valeur ajoutée. Trois innovations ont retenu notre attention. La première est signée AriadNext, startup rennaise créatrice d’un service de validation en temps réel de documents officiels (passeports, RIB…). Leur pro-
duit, développé en partenariat avec l’administration, permet une sécurisation des souscriptions et une réduction du nombre de fraudes.

Capgemini tend un piège aux pirates

La deuxième est le système d’authentification de la société GenMSecure. Celle-ci a bâti une application ergonomique, remplaçant à la fois le traditionnel identifiant-mot de passe et les codes de validation par SMS pour toutes les transactions sensibles. Lorsqu’une opération requiert l’autorisation de l’utilisateur, celui-ci la confirme avec son téléphone, de manière sécurisée, par le biais d’un code unique. Citons enfin Capgemini, pour son positionnement sur le marché embryonnaire mais prometteur des honeypots. Un honeypot est un piège destiné aux cyberattaquants : s’il est invisible pour l’utilisateur normal, il attire dans un piège celui qui cherche à déjouer les mesures de sécurité. Quand un attaquant tente de s’introduire dans ce piège, il est automatiquement banni. Ce septième FIC s’est donc montré très positif. Plus d’une centaine d’exposants, des milliers de visiteurs et un secteur inventif.

Si le marché européen n’est rien par rapport au géant américain, le développement d’une expertise “locale” est capital dans une optique d’indépendance stratégique. Laisser les Américains ou toute autre puissance avoir pour clients des entreprises françaises revient à leur offrir l’accès à nos données… Le développement et la préservation d’une expertise française est en ce sens une priorité stratégique majeure.

Catégories
Non classé

Qu’est-ce qu’un développeur ?

Je suis un développeur. Cette phrase est une évidence désormais pour moi-même et mes collègues. Mais en quoi consiste la profession qui se cache derrière ce terme ? Cet article tente une définition du développeur, d’où qu’il vienne et où qu’il soit. Il exclut ceux qui sont passés du côté managérial de la force car ils n’ont plus le même métier.

php-web-development

Il est évident que le développeur est à classer dans le secteur tertiaire, selon la classification communément admise. Le développeur apporte une solution technique, majoritairement sous forme de code, c’est à dire de donnée (un traitement est une donnée), à partir de matière grise et d’outils informatiques. Son métier n’a aucun lien direct avec le monde des objets physiques. Il ne peut avoir un lien avec celui-ci qu’en contrôlant des objets électromécaniques ne faisant pas partie de son domaine de compétence propre. Il ne travaille que dans le monde du logiciel.

Le travail

Le travail du développeur est en 3 parties, souvent confiées à d’autres acteurs à mesure que les équipes grandissent :

  • Il doit tout d’abord analyser et comprendre un problème. Parfois le problème doit être extrait des pensées confuses d’un non-technicien ce qui n’arrange rien. Heureusement le chef de projet a été inventé pour le dialogue client ! Si l’équipe ne travaille pas avec les méthodes agiles, un cahier des charges est produit puis validé par le client.
  • Le développeur doit ensuite trouver une solution technique à un besoin et la traduire en code. Dans les équipes de taille réduite c’est le développeur qui découpe son travail lui-même. Plus la taille augmente, plus il est cantonné à une partie infime du tout.
    Cette partie est le cœur nucléaire du développement (ou l’usine à gaz, c’est selon), l’analyse et la programmation sont la définition même du métier. Ici le développeur utilise son intelligence pour reproduire sous forme de traitements informatiques le comportement attendu dans les spécifications de la tâche qui lui est attribuée. Il utilise pour cela, des notions théoriques, son expérience mais aussi sa vision des choses et sa manière de penser.
  • La troisième partie est la livraison : la solution technique doit être rendue disponible au client. Cette partie comprend l’installation, la documentation et la démonstration. Dans les équipes de taille supérieure, des personnes sont attribuées spécifiquement à cette tâche. Le débogage éventuel, qui suit cette phase, entre dans la même catégorie que la production technique initiale. Le bug est la conséquence d’une malfaçon (humainement normale ou non).

La formation initiale

La formation d’un développeur est assez hybride, entre une formation d’ingénierie et une formation artisanale. Très souvent, surtout en école privée, le développeur est également formé au management, en vue d’une évolution future vers des postes de ce type. Dès son premier jour de formation, souvent même avant, le futur développeur pratique la programmation. La conception n’est pas encore une préoccupation pour lui mais rapidement, par l’échec pratique et la formation théorique, l’apprenant va commencer à concevoir des systèmes de plus en plus complexes, réutilisables, interopérables et maintenables.

La virtualité du code détermine le mode de formation. C’est parce que coder n’a pas d’autre conséquence sur le monde réel que de consommer de l’énergie, que le développeur peut échouer et recommencer tant qu’il le souhaite, avant de rentrer dans le monde professionnel où son temps devient de l’argent.

Deux grands courants s’affrontent concernant l’instruction des développeurs : l’approche projet et l’approche magistrale.

Pour les tenants de l’approche projet, l’apprenant doit au cours de son cursus, mettre en application ses compétences dans des projets encadrés. Il sera noté à la fois sur ces projets et sur des compétences théoriques dispensées pendant des cours. Cette approche a l’avantage d’harmoniser le niveau technique d’une promotion, mais au prix de la créativité des plus entreprenants.

L’approche magistrale, elle, ne note que sur les compétences théoriques. Elle laisse à la curiosité des apprenants l’apprentissage pratique. Son inconvénient principal est d’avoir en sortie des niveaux assez disparates de compétences pratiques, variant selon la curiosité de chacun. Pour cela, elle se retrouve plus dans les facultés que dans le privé, qui souhaite maintenir une « cote » homogène à son diplôme.

La profession n’exclut pas les autodidactes, bien qu’ils puissent avoir plus de difficultés à entrer et à progresser dans l’univers de la grande entreprise.

La formation continue

La formation d’un développeur n’est jamais terminée. A moins qu’il ne travaille dans le seul entretien d’un existant sénescent (COBOL, vieux mainframes …), le développeur a le devoir de se tenir informé des nouvelles technologies du numérique en général. Le développeur étant souvent technophile (technocritique à minima) cette partie ne lui pose en général aucun problème.

La seconde obligation du développeur est de ne jamais arrêter son entraînement. A l’image des maîtres des anciens Métiers, il doit toujours être en recherche de l’amélioration. Le développeur est un véritable artisan : le seul moyen qu’il possède d’augmenter sa productivité est de s’améliorer lui-même, nulle machine ne peut remplacer l’essence de son métier qui est de concevoir (lorsque ce jour sera venu, il faudra sérieusement s’inquiéter).

Si le développeur doit tendre à la perfection individuelle, la même chose vaut pour l’équipe. La méthode utilisée, en revanche, diffère fondamentalement selon que l’on se trouve dans une petite équipe ou dans une équipe plus grande. Dans une petite équipe, l’amélioration se fera principalement par la discussion et la découverte de synergies entre les membres. Dans une équipe plus grande, il est impensable qu’un développeur connaisse bien tous ses collègues ! L’amélioration des performances devient une question organisationnelle dépendant de la hiérarchie. Elle passe souvent par une division du travail et une standardisation des environnements et méthodes. Le développeur a moins son mot à dire.

Les outils

Pour son travail le développeur utilise un ordinateur. Cela paraît idiot à dire mais mérite d’être dit car cela inclut deux choses : l’ordinateur comme interface physique (clavier, souris, écran(s)) et l’ordinateur comme plateforme logicielle. L’efficacité des deux influe sur la productivité du développeur.

Le développeur accomplit sa mission en utilisant un ou plusieurs langages de programmation. Ils sont traduits en langage machine par un compilateur ou un interpréteur. Très souvent, le développeur entoure cet outil fondamental d’une suite d’autres outils, qui constituent son environnement de développement. Dans les faits, la multitude des options de configuration permet de ne jamais trouver deux développeurs avec exactement le même environnement. Si, pour garantir la cohérence d’une équipe, certains outils doivent être partagés, la majeure partie est entièrement personnalisable. Même dans les équipes massives le développeur ne sera jamais complètement standardisé.

La productivité de l’environnement est un facteur majeur de productivité du développeur. Avec cet environnement il va produire du code de deux types : applications et modules. Les applications sont destinées à un usage précis et sont un agrégat de modules, cimentés par du code. Les modules sont, eux, destinés à être réutilisés dans plusieurs applications, ils peuvent être considérés comme des outils et comme des sous-produits.

Les modules sont un facteur crucial de la productivité d’une équipe de développeurs. Ils permettent de ne pas réinventer la roue à chaque fois, en posant des interfaces simples sur des procédures plus complexes. Ils ont également l’intérêt de factoriser le code : un module crée une fois peut être appelé dans plusieurs parties d’un code. Enfin, ils le remplacement aisé de parties d’un programme, en minimisant les changements à opérer sur le tout.

Rapport au travail et à l’emploi

Le développeur est un employé de bureau, qu’il travaille dans des locaux d’entreprise, chez lui ou bien en nomade. Son rapport à l’emploi est exactement le même que pour un employé de bureau classique et dépend fortement de la structure dans laquelle il choisit de travailler. Le poste et la mentalité d’un développeur change radicalement selon qu’il soit dans une PME ou une grosse structure. Son appréciation de son travail dépend principalement de la taille de l’équipe à laquelle il est intégré.

Un point cependant change fondamentalement par rapport à l’employé de bureau, point qu’il peut partager avec l’ingénieur ou le chercheur : Le rapport du développeur à son travail est essentiellement d’ordre artisanal. Le développeur s’identifie plus volontiers par ce qu’il fait, que par où il le fait. Chez le col blanc « classique » c’est l’entreprise et la position hiérarchique qui identifient la personne. Ce penchant artisanal se retrouve également dans les projets personnels, plus ou moins nombreux et achevés, que le développeur réalise en extra-professionnel, caractéristique que l’on retrouve chez certains artisans.

Un développeur travaillant en grande entreprise a tendance à faire partie d’équipes plus grandes, tenant souvent plus de la chaîne de montage que de l’équipe humaine. Cela n’est pas toujours vrai mais ça change le rapport qu’il peut avoir à son travail : en grande équipe il s’identifie plus par sa position, tel l’employé de bureau, que par ses réalisations. Le développeur qui ne travaille que sur une petite partie d’un tout sans en avoir forcément une vision d’ensemble, aura bien plus de mal à s’y reconnaître.

Le pouvoir

Le développeur est un technicien : c’est-à-dire qu’il est formé à des techniques auquel le commun des mortels ne comprend rien. Il a donc un ascendant sur l’utilisateur final non-technicien. Dans beaucoup de situations, le conseil est une obligation légale. Dans le reste des cas, c’est au développeur en son âme et conscience de décider quel degré de transparence, d’honnêteté et de pédagogie il appliquera.

Le technicien-développeur produit du code. Ce code n’est pas neutre : il impose à l’utilisateur la vision du commanditaire, déformée par le développeur. Lorsque les traitements dans l’entreprise sont entièrement manuels, l’empirisme et le ressenti produisent des méthodes de travail relativement souples, sauf ordres stricts de la direction. Lorsque l’on remplace l’humain par l’ordinateur il se produit une réduction de la créativité. L’ordinateur est aussi créatif que drôle. La créativité d’une équipe humaine est bridée par la rigidité de la machine. Si le développeur à le pouvoir d’assouplir et de rendre ergonomiques ses solutions, jamais il ne pourra s’empêcher d’imposer de la rigidité.

Le code n’est pas non plus sans conséquences économiques. En particulier le code de mauvaise qualité. La gravité économique de la sous-qualité dépend de deux facteurs : la criticité de l’application et l’ampleur des défauts. Le principe de Peter est fondamental lorsqu’il s’agit de manager des développeurs. Un mauvais développeur placé à un endroit stratégique peut couler, ou gravement handicaper, une entreprise. Mieux vaut pas d’outil informatique du tout, qu’un outil qui représente une perte de productivité à un poste donné. D’autant que le développement à un coût non-négligeable.

Conclusion

Le développeur est une sorte d’hybride entre deux tendances : l’artisan-codeur et le salarié du tertiaire. Le poids de chaque tendance varie selon le contexte de travail. Armé d’un ordinateur et de son cerveau, le développeur va, seul ou en équipe, bâtir les briques de la société de l’information, colonne vertébrale de nos sociétés post-industrielles. Tout, aujourd’hui, est informatisé. Si la technique informatique n’est pas neutre en elle-même, les traitements informatiques le sont encore moins car elles sont des œuvres humaines. L’humain derrière chaque application se trouve être un développeur, avec ses compétences, son éthique, sa vision du monde, sa manière de travailler et ses idées. Si ce qu’il réalise est soumis à des contraintes (contractuelles, physiques, informatiques), il joue néanmoins un rôle majeur dans la manière dont se dessine la société de demain, rôle proportionnel à la place qu’occupe l’informatique dans celle-ci.

Catégories
Non classé

Agilité et maurassisme

Il est des choses comme ça que l’on croirait très éloignées, impossibles à rapprocher mais qui pourtant présentent des aspects communs que l’on ne remarque souvent que par hasard, celui d’une lecture, d’une rencontre d’un événement.Ici deux courants de pensées que j’aimerais rapprocher :

  • L’Agilité, réponse du bon sens à la rigidité et la lourdeur des idéologies industrielles regroupées sous l’appellation d’Organisation « Scientifique » du Travail (O.S.T) : Néo-Taylorisme, Juridisme, Procédurisme …
  • Le Maurassisme, ou positivisme politique en réponse aux idéologies politique issues de la révolution libérale : Marxisme, Libéralisme, Nazisme …

Premier constat : les deux sont des réponses à des concepts apparus autour de la révolution industrielle ou bien grâce à elle.

Second constat : les deux se basent sur l’étude rationnelle des faits pour tirer des conclusions, ce sont des contre-idéologies.

Troisième constat : les deux constatent la faillibilité de l’humain et plutôt que de la nier, font avec et bâtissent des systèmes résistants.

Quatrième constat : les deux prônent des systèmes basés sur les compétences de chaque acteur et la liberté absolue d’exercer un rôle bien précis plutôt que de vouloir des rôles larges de touche-à-tout bon-à-rien.

Cinquième constat : les deux voient la réorganisation interne du système comme un moyen d’adaptation.

Sixième constat : les deux voient d’un bon œil l’auto-organisation des acteurs.

Septième constat : les deux ont pour but de servir le plus efficacement le commanditaire.

Les deux ne servent pas les mêmes buts, mais je trouvais intéressant ce rapprochement.