Une conviction commune : accélérer ne suffit pas

Notre conviction commune est simple : l'intelligence artificielle accélère la production, mais elle n'endosse pas la responsabilité.

Elle accélère l'accès à l'information. Elle automatise une partie des analyses, reformule des documents, rapproche des données, produit des synthèses, propose des scénarios. Pour une organisation, le gain est réel. Il serait absurde de le nier.

Mais cette accélération crée une confusion dangereuse : parce que l'information devient plus accessible, on peut croire que la décision devient plus simple. C'est souvent l'inverse. Quand produire devient facile, décider devient plus exigeant. Quand l'analyse devient abondante, le discernement devient rare.

La vitesse peut accélérer une erreur.

Un document produit plus vite n'est pas nécessairement un document juste. Un plan projet bien structuré n'est pas nécessairement pilotable. Une synthèse convaincante n'est pas nécessairement complète. Une recommandation bien formulée n'est pas nécessairement responsable.

La forme peut masquer un raisonnement incomplet. La fluidité peut rendre présentable une hypothèse fragile. La vitesse peut accélérer une erreur.

La question centrale n'est donc pas seulement : que peut-on produire plus vite ? La question qui compte dans les projets sensibles est : qui répond de ce qui est compris, décidé, lancé, signé, livré ou mis en production ?

La voiture autonome montre que la responsabilité ne disparaît pas

L'analogie avec la voiture à délégation de conduite est éclairante. En France, le sujet n'est pas traité comme une simple question technique.

Le code de la route distingue les situations où le conducteur exerce le contrôle et celles où les fonctions de conduite sont déléguées à un système automatisé, dans des conditions prévues.

Dès lors, la responsabilité peut se déplacer selon l'état réel du système, les conditions d'utilisation, la reprise en main, les informations fournies au conducteur, les défaillances éventuelles et les acteurs impliqués.

Si un accident survient, la question n'est pas seulement : "le système a-t-il fonctionné ?" Elle devient une série de questions de responsabilité :

• qui avait le contrôle ?
• le conducteur devait-il reprendre la main ?
• le constructeur avait-il correctement défini les conditions d'utilisation ?
• l'information fournie était-elle suffisante ?
• le système a-t-il respecté son domaine prévu ?
• un équipementier a-t-il fourni un composant défaillant ?
• l'assureur intervient-il ?
• une faute peut-elle être établie ?

Cette logique est plus proche du pilotage de projets critiques qu'on ne le croit. L'automatisation ne fait pas disparaître la responsabilité. Elle oblige au contraire à la localiser plus précisément.

En Europe, la directive 2024/2853 sur la responsabilité du fait des produits défectueux confirme ce mouvement : les logiciels, y compris les systèmes d'IA, entrent dans le champ des produits pouvant engager une responsabilité en cas de dommage lié à un défaut.

En France, l'ordonnance du 14 avril 2021 sur les véhicules à délégation de conduite montre aussi que l'automatisation impose de clarifier le contrôle, les conditions d'usage, l'information et les responsabilités.

Ce ne sont pas des détails juridiques. Ce sont des signaux de fond : plus les systèmes deviennent autonomes, plus la chaîne de responsabilité doit être explicite.

Dans l'entreprise, le risque reste porté par l'organisation

Dans l'entreprise, la même question se pose. Un système peut produire une analyse, mais il ne porte pas seul le risque.

Il ne signe pas le contrat. Il ne répond pas devant le comité d'audit. Il ne gère pas la crise client. Il ne supporte pas le coût d'un arrêt de production. Il ne reconstruit pas la confiance après un incident.

Il ne va pas expliquer à la direction générale pourquoi une donnée sensible a été exposée, pourquoi un fournisseur était hors cadre, pourquoi un budget a dérivé ou pourquoi un projet critique a été lancé sur une hypothèse non vérifiée.

Dans un projet critique, la responsabilité se situe rarement à un seul endroit. Elle est distribuée entre plusieurs acteurs :

• le sponsor qui a arbitré ;
• la direction métier qui a exprimé le besoin ;
• la DSI qui a intégré la solution ;
• l'éditeur qui a fourni le produit ;
• l'intégrateur qui l'a configuré ;
• le fournisseur de données ;
• le RSSI, le DPO, le contrôle interne ;
• les équipes opérationnelles ;
• parfois l'assureur ;
• parfois le conseil externe.

Quand un problème survient, chacun peut expliquer que son périmètre était limité. Mais pour l'entreprise, le dommage est global.

Trois cas concrets où l'accélération ne qualifie pas le risque

Une réponse à appel d'offres peut engager trop vite l'entreprise

Premier cas : une réponse à appel d'offres est accélérée par des outils de génération et de synthèse. Les équipes gagnent du temps. Les mémoires techniques sont mieux structurés. Les références sont plus rapidement mobilisées.

Puis une proposition part avec un engagement irréaliste, une promesse de délai non tenable ou une formulation contractuelle insuffisamment relue.

Qui paie si le client signe sur cette base ? Le collaborateur qui a produit la première version ? Le commercial qui a envoyé l'offre ? La direction qui a fixé l'objectif de productivité ? Le juriste qui n'a pas relu ? L'éditeur de l'outil ?

En pratique, c'est l'entreprise qui portera la tension commerciale, contractuelle et réputationnelle. La production aura été accélérée, mais le risque n'aura pas été qualifié.

Un reporting peut être convaincant et faux

Deuxième cas : une direction financière accélère ses analyses budgétaires, ses commentaires de reporting et la détection d'écarts. Les tableaux sont plus rapides à commenter. Les explications sont mieux écrites.

Mais une anomalie vient d'un mauvais référentiel, d'un reclassement comptable mal compris ou d'une donnée source incomplète. Le commentaire final donne une explication plausible mais fausse. Le comité de direction arbitre sur cette base.

Qui paie ? La finance ? Le contrôle de gestion ? La DSI ? Le fournisseur de l'outil ? Le métier qui a mal alimenté la donnée ?

Là encore, l'accélération ne remplace ni la compréhension du modèle de données, ni l'expérience des cycles de clôture, ni la capacité à détecter une explication trop confortable.

Un projet SI peut sembler cadré sans être maîtrisé

Troisième cas : dans un projet de transformation SI, les équipes produisent plus vite un cahier des charges, une cartographie applicative, une liste d'exigences, une analyse des risques, un planning. Tout paraît plus cadré.

Pourtant, le projet dérive parce que les dépendances métier ont été sous-estimées, les interfaces critiques mal identifiées, la conduite du changement réduite à quelques formations, les contraintes réglementaires traitées trop tard.

Qui paie ? Le chef de projet ? L'AMOA ? L'intégrateur ? Le sponsor ? La DSI ? Le comité de pilotage ?

Chacun peut avoir produit sa partie. Personne n'a vraiment tenu l'ensemble.

Ces situations montrent le même phénomène : l'accélération de la production ne garantit pas la qualité du cadrage. Or les projets critiques échouent rarement parce qu'il manque un document. Ils échouent parce que les mauvaises questions n'ont pas été posées assez tôt, parce que les responsabilités étaient floues, parce que les arbitrages ont été repoussés, parce que les risques faibles sur le papier étaient forts dans le réel, parce que les dépendances humaines, techniques ou contractuelles ont été sous-évaluées.

Personne n'a vraiment tenu l'ensemble.

Les profils expérimentés portent une responsabilité de discernement

C'est là que les profils expérimentés deviennent primordiaux.

Un profil expérimenté ne se contente pas de produire. Il engage un jugement. Il sait reconnaître ce qui manque. Il sait repérer une hypothèse trop propre. Il sait entendre ce qu'une équipe ne dit pas.

Il sait distinguer un risque théorique d'un risque qui va vraiment bloquer. Il sait qu'un planning peut être cohérent dans un tableur et impossible dans une organisation.

Il sait qu'un contrat peut être signé et rester inopérant si les responsabilités opérationnelles ne sont pas tenues. Il sait qu'un outil peut être conforme en apparence et dangereux dans ses usages réels.

Surtout, un profil expérimenté endosse une responsabilité de discernement. Cela ne signifie pas qu'il devient juridiquement responsable de tout. Cela signifie qu'il accepte de :

• prendre position dans l'incertitude ;
• expliquer pourquoi une option est robuste ou fragile ;
• signaler ce qui n'est pas suffisamment maîtrisé ;
• formuler les conditions de succès ;
• documenter les réserves ;
• provoquer un arbitrage quand le projet avance sur une zone grise.

C'est cette responsabilité-là que recherchent les dirigeants. Pas seulement une capacité d'exécution. Pas seulement une expertise théorique. Une capacité à sécuriser une décision avant qu'elle n'engage l'organisation.

L'expérience apporte la mémoire des conséquences

L'expérience apporte aussi une mémoire des conséquences. C'est une différence majeure. Celui qui a déjà vu un ERP déraper, une migration rater, une clôture financière être fragilisée, une relation fournisseur devenir asymétrique, une donnée critique perdre sa traçabilité ou un comité de pilotage s'enfermer dans des indicateurs rassurants ne lit pas un livrable de la même manière. Il ne cherche pas seulement si le document est bien écrit. Il cherche ce qui peut casser.

Dans un contexte où les livrables deviennent plus nombreux, plus rapides, plus convaincants, cette mémoire devient décisive. Le risque ne sera pas l'absence de production. Le risque sera l'excès de production non qualifiée.

La question "qui paie ?" doit être posée avant l'incident

La question "qui paie ?" doit donc être posée avant l'incident, pas après. Qui paie si une recommandation conduit à un mauvais arbitrage ? Qui paie si un processus applique une règle erronée à grande échelle ? Qui paie si une donnée est utilisée hors cadre ? Qui paie si une équipe s'appuie sur une synthèse qui a oublié une contrainte contractuelle ? Qui paie si un projet accéléré devient plus difficile à auditer parce que les décisions intermédiaires ne sont pas tracées ?

Dans une organisation mature, la réponse ne consiste pas à refuser les outils d'accélération. Elle consiste à clarifier les rôles. Un outil peut proposer, accélérer, simuler, reformuler, comparer. Mais l'organisation doit désigner qui valide, qui arbitre, qui documente, qui contrôle, qui assume. Il faut une chaîne de responsabilité aussi claire que la chaîne de production.

Cela change la manière de piloter les projets. Un comité de pilotage ne peut plus se contenter de demander si les livrables sont produits. Il doit demander qui les a qualifiés.

Une direction ne peut plus seulement regarder le gain de temps. Elle doit regarder le niveau de risque déplacé.

Une DSI ne peut plus seulement intégrer un outil. Elle doit définir ses conditions d'usage, ses limites, ses journaux de décision, ses points de contrôle.

Une direction métier ne peut plus dire que l'outil a proposé. Elle doit savoir pourquoi elle a retenu ou écarté la proposition.

Accélérer sans perdre la maîtrise

Dans les projets critiques, l'IA ne supprime donc pas le besoin d'expertise senior. Elle déplace la valeur vers le jugement, l'arbitrage, la responsabilité et la maîtrise. Les profils les plus utiles ne seront pas ceux qui produisent le plus vite. Ce seront ceux qui savent ralentir au bon endroit, poser la bonne question, refuser une réponse trop facile, documenter une décision, organiser la contradiction et protéger l'entreprise contre une accélération mal maîtrisée.

La conviction commune BigMentor est là : aider les organisations à accélérer sans perdre la maîtrise. Cela suppose des méthodes, mais surtout des profils capables d'endosser une responsabilité de conseil, de contradiction et de décision. Des profils qui ne se contentent pas de livrer une analyse, mais qui disent ce qu'elle permet de décider, ce qu'elle ne permet pas de décider, et ce qu'il serait dangereux d'ignorer.

C'est aussi ce qui fonde notre relation avec les experts. Nous ne cherchons pas seulement des profils qui savent produire vite ou intervenir sur un sujet. Nous cherchons des personnes capables de tenir un regard, de partager une conviction, de transmettre des repères, et d'aider un client à sortir d'une zone grise sans créer une nouvelle dépendance.

Un projet accéléré reste un projet humain dans ses conséquences.

Un projet accéléré reste un projet humain dans ses conséquences. Si la production va plus vite, la responsabilité doit devenir plus explicite. Sinon, l'organisation ne devient pas plus performante. Elle devient simplement plus rapide à exposer ses angles morts.

Repères utiles et sources

• Code de la route – véhicules à délégation de conduite : en France, le code de la route prévoit un régime spécifique de responsabilité pénale pour les véhicules à délégation de conduite.
• Ordonnance n° 2021-443 du 14 avril 2021 : elle encadre les conditions d'utilisation de ces véhicules et l'information préalable du conducteur.
• Directive (UE) 2024/2853 : elle actualise le régime européen de responsabilité du fait des produits défectueux et intègre les logiciels, les systèmes d'IA et certains services numériques liés au fonctionnement d'un produit.
• Ces repères ne suffisent pas à trancher chaque cas concret, mais ils confirment un point essentiel : quand l'automatisation produit un effet dans le réel, la chaîne de responsabilité doit être pensée, documentée et gouvernée.