CONFIGURATION UPDATE

Description

technical field

[0001] This disclosure falls within the domain of techniques for configuring and updating software and applications installed on devices communicating with one or more servers. It is particularly relevant to situations where the fleet of devices includes devices with varied internal software ("firmware") that is initially unknown to such servers. Previous technique

[0002] In the field of application software maintenance, the responsibility for updates rests almost exclusively with the software provider, typically the "applications" installed on smartphones. However, the internal software ("firmware") of such devices can vary greatly due to the wide variety of manufacturers, device models, and even firmware versions for the same device model. From the perspective of an application provider such as the plaintiff, new firmware versions are therefore released very frequently. When a new firmware version is released, typically with a new device model, the application's functionality may be degraded or even become completely incompatible with the new device.To maintain application compatibility across as many devices as possible, application providers regularly deploy updates to the entire device ecosystem, even though only a small fraction of devices (the newest ones) actually require them. This type of maintenance is complex, costly, and inefficient. US 2014 / 317613, US 2009 / 319848, and US 2010 / 333081 address such update issues. Summary

[0003] This disclosure improves the situation.

[0004] A system is proposed comprising at least one terminal and one server capable of communicating with each other, with a corresponding back-end application and front-end application installed on the server and terminal respectively, and the server having access to at least one database. The database includes: a list of sets of identifiers, each set of identifiers comprising * a terminal identifier, * a hardware layer identifier, and * an operating system identifier; a lookup table between * each pair of hardware layer identifier and operating system identifier existing in said list, and * a configuration file, itself stored in at least one database. The terminal and the server are configured to coordinate with each other so that, upon opening a communication session between the terminal and the server: a. transmit, from the terminal to the server, a set of identifiers comprising a terminal identifier, a terminal hardware layer identifier, and an operating system identifier implemented on the terminal; b. upon receipt on the server from the terminal of the set of identifiers, compare it to the contents of the database, and if there is a match between the transmitted set of identifiers and a set of identifiers from said list, continue the communication session without updating the terminal configuration; if there is no match between the transmitted set of identifiers and the sets of identifiers from said list, and if there is a match with a pair of identifiers from a hardware layer and an operating system in the lookup table, transmit back, from the server to the terminal, the configuration file associated with said pair according to the lookup table;in the event of no match with a pair of identifiers from a hardware layer and an operating system in the lookup table, identify, in the lookup table and by applying pre-established rules, a pair of identifiers from a hardware layer and an operating system closest to that of the set of identifiers transmitted from the terminal, then transmit back, from the server to the terminal, the configuration file associated with the combination identified according to the lookup table, said file being transmitted with an indicator qualifying the configuration file as temporary; c. populate the database with the set of identifiers received and any association resulting from the identification d. upon receipt of a configuration file on the terminal from the server, implement said configuration file in the front-end application, and; if and only if said configuration file contains an indicator qualifying the file as temporary, switch the front-end application into test mode.

[0005] The terminal and server can also be configured to: e. in response to a predetermined validation action by the user via the terminal, remove an indicator qualifying the file as temporary on the terminal, switch the front-end application to normal mode, transmit, from the terminal to the server, a command to validate said temporary configuration file f. upon receipt on the server from the terminal of the command to validate the temporary configuration file, remove an indicator qualifying the file as temporary in the corresponding database association.

[0006] According to another aspect, a configuration process implemented by a terminal is proposed, comprising operations a and d, and optionally e, above.

[0007] According to another aspect, a configuration process implemented by a server is proposed, comprising operations b and c, and optionally f, above.

[0008] In another aspect, a terminal is proposed that is configured for the implementation of a process as defined above.

[0009] In another aspect, a server is proposed that is configured for the implementation of a process as defined above.

[0010] In another aspect, a computer program is proposed that includes instructions for implementing all or part of a process as defined herein when executed by a processor. In another aspect, a non-transient, computer-readable recording medium is proposed on which such a program is recorded.

[0011] By providing configuration files tailored to each new device connecting to the server (or device with a new configuration), it's possible to reduce the number and frequency of full application updates that need to be deployed across all devices. Creating a configuration file is much easier than deploying a full update, primarily because compatibility only needs to be verified with the specific device or configuration rather than with the entire fleet of devices. The size of a configuration file is significantly smaller than that of a full application update, thus reducing the time and hardware and software resources required to transmit and install such files over telecommunications networks.From the perspective of terminal users, it becomes pointless to update the application as long as the terminal being used is not modified.

[0012] From a global perspective, making a new configuration file available benefits each user with a terminal that has a corresponding configuration, without impacting other users of the service. Upstream, a user implementing a configuration file in "test" mode validates whether or not it functions correctly, so intervention from an application provider's operator is only necessary in case of a malfunction. Brief description of the drawings

[0013] Other features, details, and advantages will become apparent upon reading the detailed description below and analyzing the attached drawings, on which: Fig. 1 [ Fig. 1 ] represents elements of the system according to a mode of embodiment. Fig. 2[ Fig. 2 ] is an implementation diagram according to a method of embodiment. Fig. 3 [ Fig. 3 ] represents data exchanges between elements of a system according to an embodiment. Context

[0014] In the following, the French terms "application devant" and "application dorsale" are used to distinguish what a technician, even a non-English speaker, calls the "frontend" and the "backend," respectively. Similarly, the French terms "logiciel interne" and "application / logiciel application" are used to distinguish what a technician calls "firmware" and "software," respectively.

[0015] The following was implemented by the applicant in the context of half-duplex communications via mobile telephone networks, better known by the acronym "PTT" for "Push-to-Talk," and in particular its services known under the trade names "Team on the Run" and "Team on Mission." Essentially, it involves offering communication solutions that, from the users' perspective, appear to behave like walkie-talkie radio transceivers (holding down a button to speak on a channel, releasing the button to free up speaking on the channel and switch to listen mode), while also offering features enabled by recent communication networks and protocols (audio / video combination; compatibility and interoperability with a large number of mobile or fixed terminals; communication encryption; geolocation; on-the-fly network switching; etc.).In practice, the implementation of the following is therefore particularly beneficial in the context of PTT communications, but not limited to it.

[0016] The implementation of the following is particularly advantageous in situations where physical access to terminals and certain configuration information is difficult or even impossible for the application software administrator. This is typically the case for confidentiality and security reasons when terminals are used by individuals in sensitive activities (police, law enforcement, civil defense, emergency services in the event of a disaster, operations in areas with unreliable network coverage, etc.). Description of the implementation methods

[0017] Reference is now being made to the [ Fig. 1A system comprises at least one terminal 1 (here, three), a server 2, and a database 3. Terminal 1 and server 2 are each devices designed to communicate (i.e., exchange data) over one or more telecommunication networks, including with each other. Terminal 1 can thus be a fixed or mobile communication device, for example, a smartphone or a computer, available to a user. Server 2 refers to equipment located remotely from terminal 1 and managed by a service provider, such as an application provider. Database 3 is accessible to server 2. Database 3 is represented here as a separate entity from server 2. Alternatively, database 3 is a subset of server 2. Data exchanges between terminal 1, server 2, and database 3 may involve intermediate components.In other words, data transmissions are not necessarily direct between the aforementioned elements.

[0018] Terminal 1 includes a human-machine interface. The term "human-machine interface" is used generically to refer to all the equipment and software components of Terminal 1 that allow the user to interact with it, both to receive information from Terminal 1 and to input information into Terminal 1. For example, the human-machine interface takes the form of a touchscreen. Alternatively, the human-machine interface can take other forms, such as a microphone for acquiring voice commands, a speaker for broadcasting information in audio form, a vibrator for providing haptic feedback, or a combination of such components.

[0019] Terminal 1 includes at least one processor and one memory unit configured so that the processor executes programs stored on the memory unit. The programs include: Internal software (“firmware”), generally installed during the manufacturing and factory configuration of terminal 1, and subsequently updated under the responsibility of the entity marketing terminal 1; application software, generally installed a posteriori to the initiative of the terminal 1 user and updated under the responsibility of an entity which is often separate from the terminal 1 provider.

[0020] Terminal 1 has the front end of an application installed, while the back end of the application is installed on server 2.

[0021] In this context, Server 2 can comprise several devices and software components arranged to interact with each other. In other words, Server 2 is not necessarily a single, monolithic physical device but can instead include several distinct modules located remotely from one another. Server 2 includes, for example, at least one processor and one or more memory units for storing databases accessible to at least one processor. In the example described here, Server 2 also includes an application programming interface, or API, for « Application Programming Interface The API interfaces between a communication module of server 2 and database 3. One or more APIs can also be provided for operators to access.

[0022] Database 3 contains at least the following data: a list I of sets of identifiers; a lookup table II; configuration files D, including optionally one or more "temporary" configuration files referenced D, Z.

[0023] Each set of identifiers in list I includes: * a terminal identifier A, * a hardware layer identifier B, and * an operating system identifier C. In practice, list I lists each terminal 1 that connects to server 2 with information about its hardware layer and operating system. When a terminal 1 changes its hardware layer and / or operating system, and then connects again to server 2, it therefore generates a new entry in list I (a new set of identifiers distinct from the set of identifiers generated during its previous connection).

[0024] The correspondence table includes associations between: * each pair B; C of an existing hardware layer identifier and operating system identifier from list I, and * a configuration file D. Thus, list I can include several sets of identifiers that differ by the terminal identifier A but have the same hardware layer identifier B and the same operating system identifier C. In this case, the lookup table II includes a unique association between said pair of identifiers B; C and a configuration file D. A plurality of distinct terminals but with a common configuration are therefore indirectly associated with the same configuration file D. This situation corresponds in practice to a fleet of similar terminals that can be configured similarly.

[0025] Reference is now being made to [ Fig. 2 ] And [ Fig. 3At least one terminal 1 and server 2 are configured to coordinate with each other to perform operations. This is referred to as "coordination" because some operations are performed primarily from terminal 1 while other operations are performed primarily from server 2. On the [ Fig. 2 Icons representing terminal 1 and server 2 are attached to the operations to identify the system element initiating each operation according to the described implementation. However, for ease of understanding, the implemented operations are presented in chronological order, regardless of the system element that implements them. It remains easy to decompose the operations according to the system element that implements them, as in [ Fig. 3], in order to distinctly define a process implemented by the terminal, and a process implemented by the server, linked together in such a way that they form only one general inventive concept.

[0026] In the example described here, the opening of a communication session between terminal 1 and server 2 triggers the operations described below. In other words, the configuration update is triggered by terminal 1 connecting to server 2. Alternatively, other triggers are possible, such as an action or interaction by the user of terminal 1 via their user interface.

[0027] The processes for which terminal 1 and server 2 are configured include the operations described below.

[0028] The first step, Operation 101, includes: a. transmit, from the terminal to the server, a set of identifiers. The set of identifiers includes: an identifier A 1 of terminal 1, an identifier B 1 of a hardware layer of terminal 1, and an identifier C 1 of the operating system implemented on terminal 1.

[0029] The transmission of the set of identifiers A 1 , B 1 , C 1 can take the form of a response to a request issued by the server 2, or be initiated by the terminal 1, for example included in a request to update configuration files or a request to establish or access a communication session.

[0030] An operation 102 includes: b. upon receipt on server 2 from terminal 1 of the set of identifiers A 1 , B 1 , C 1 , compare (said set) to the content of database 3.

[0031] Depending on the results of the comparisons, various operations are implemented. In particular: i / If there is a match between the transmitted set of identifiers A1, B1, C1 and a set of identifiers from list I, continue the communication session without updating the configuration of terminal 1. In this case, it is assumed that terminal 1, in its current configuration, had already connected to server 2 and that its configuration file is therefore up to date: there is no need to update it again, and the update processes can therefore be terminated to continue the communication session in a known manner. ii / If there is no match between the transmitted set of identifiers A1, B1, C1 and the sets of identifiers from said list I, and if there is a match with a pair B1, C1 of identifiers from a hardware layer and operating system in the lookup table II, implement operation 103 described below.iii / in case of no match with a pair B x , C y of identifiers of a hardware layer and operating system of the correspondence table II, . implement an operation 104 and an operation 105 described below.

[0032] Operation 103 consists of transmitting back, from server 2 to terminal 1, the configuration file D 1,1 associated with the pair B 1, C 1 according to the lookup table II. This situation corresponds to that of a terminal 1 connecting for the first time, at least in its current configuration, to server 2 (since it has never been registered in database 3 with the identifiers B 1 and C 1). Nevertheless, the existence of the identifier pair B1 and C 1 implies that a configuration file D 1,1, presumably suitable for such a configuration, is available in database 3. This existence may result from a prior implementation of the configuration file D 1,1 by an operator on server 2 and / or, for example, from the prior implementation of a process such as the one described here by another terminal with the same configuration (B 1 and C 1).It is then understood that the implementation of the processes described here by a first terminal subsequently benefits terminals with similar configurations.

[0033] Following operation 103, the processes can continue by implementing operations 106 and / or 107 described below.

[0034] Operation 104 includes: identifying, in the correspondence table II and by application of pre-established rules, a pair B x , C y of identifiers of a hardware layer and operating system closest to that of the set of identifiers B 1 , C 1 transmitted from terminal 1.

[0035] The pre-established rules for defining the pair of identifiers Bx, Cy closest to the transmitted identifier pair B1, C1 are constructed in such a way as to maximize the probability that the corresponding configuration file Dx, y is also compatible with the configuration (B1, C1) of terminal 1, even if the configuration of terminal 1 is not strictly identical to the configuration for which the configuration file Dx, y was created. For example, the notion of proximity can be defined by applying a first rule classifying pairs with a common identifier B (B1 = Bx) as closer to each other than pairs with a common identifier C (C1 = Cy), with pairs with a common identifier C being themselves closer to each other than pairs with neither a common identifier B nor a common identifier C.A second rule can then further refine the ranking of pairs that receive the same ranking from the first rule. Such a second rule could, for example, rank pairs as closest to each other when both identifiers (B1 and Bx, or C1 and Cx) correspond to versions from the same designer / manufacturer and / or when their version numbers are close. To illustrate, the rules could be constructed so that a pair of identifiers B1 = "bidule_phone_13" and C1 = "eOS_13.4" is considered closer to the pair of identifiers Bx = "bidule_phone_13" and Cy = "eOS_13.3" than to the pair of identifiers Bx = "G_phone_4" and Cy = "gOS_4.42". The construction of rules can be very varied but remains within the reach of a person in the field and depends on the context of use.

[0036] Alternatively, the pre-established rules can be basic, for example built to select by default the last pair of identifiers recorded in table II.

[0037] At the end of operation 104, an operation 105 is implemented. Operation 105 includes: transmitting back, from server 2 to terminal 1, the configuration file D x , y associated with the combination identified B x , C y according to the correspondence table II (identified in operation 104).

[0038] In the examples described here, the file D x , y is transmitted with an indicator or "tag" (here in the form of a "Z" reference) that qualifies the configuration file D x,y , Z as "temporary." In other words, the configuration file is identifiable as not yet validated / final. Put another way, it is a "beta version" of a configuration file.

[0039] Following operation 105, operations 106 and / or 107-108 are implemented. It should be noted that operations 106 and 107-108 are independent of each other. They can therefore be implemented in parallel, or sequentially in either direction.

[0040] Operation 106 includes: c. populating database 3 with the set of received identifiers A 1 , B 1 , C 1 and the possible association arising from the identification B 1 , C 1 , D x,y , Z.

[0041] Adding the set of identifiers A1, B1, C1 to list I is equivalent to recording / history of the connection of terminal 1 to server 2. Thus, if terminal 1 connects again later with the same configuration to server 2, the implementation of these procedures will lead to situation "i" described above: the process will be terminated to continue the communication session without updating the configuration of terminal 1. Adding the association B1, C1, Dx,y, Z to the lookup table is implemented only if such an association has just been established (in case "iii" above, but not in case "ii"). It should be noted here that adding an association pointing to a "temporary" configuration file does not necessarily imply that this association is immediately accessible to future terminals that connect to server 2.This is a context-dependent design choice: associations involving a configuration file marked as temporary and its corresponding configuration file can be hidden or made inaccessible to prevent the deployment of uncommitted configuration files. Conversely, for example, to accelerate deployment, associations involving a configuration file marked as temporary and its corresponding configuration file can be made accessible to other devices.

[0042] Operation 107 includes: d. upon receipt of a configuration file D 1,1 ; D x,y , Z on terminal 1 from server 2, implement said configuration file in the front-end application (on terminal 1).

[0043] Operation 107 does not update the application installed on terminal 1 itself, but rather corrects its interaction with the terminal 1 hardware layer through the configuration file. For example, the "raw" control signals from the hardware layer, corresponding to a user action via the terminal 1 human-machine interface, are better recognized by the application and thus better translated into software input. In the context of PTT communications, for instance, pressing, holding, and then releasing a button, whether physical or virtual, is more accurately recognized as a talk command.

[0044] Following operation 107, operation 108 is implemented. Operation 108 includes the following: if and only if the configuration file contains an indicator classifying the file as temporary, switching the front-end application of terminal 1 into test mode. Test mode allows the user to perform command tests from their terminal without disrupting the operational functioning of other terminals.

[0045] Upon completion of operations 107 or 108, the configuration update processes can be considered finished: configuration files are being tested. The user of terminal 1 can perform tests, with operator assistance if necessary. A guided test mode can be integrated into the application. For example, the user can follow instructions for interacting with the human-machine interface of terminal 1 to enable the recognition of sequences of human actions. For example, the user can be asked to simulate speaking on a PTT communication channel by pressing, holding for a predefined duration (e.g., 3 seconds), and then releasing a button (physical or virtual) on terminal 1 chosen by the user.The application's recording of command signals from the hardware layer of terminal 1 then allows them to be associated with the correct action or event to be triggered by the software layer (the application), i.e., the user's voice in the example above. In operational mode, the same user action will therefore be better "recognized" by the application.

[0046] The tests performed by the user aim to verify whether the application's behavior / functioning is correct, in order to validate the temporary configuration file. Optionally, the actions simulated by the user can be recorded to help correct the temporary configuration file (if certain user actions do not generate the expected application behavior).

[0047] Examples of tested settings and functions that can be adapted using configuration files are given below: Pressing a button, physical or virtual, holding the button down for one or more predetermined durations, then releasing the button at the end of said duration(s), for example to correspond to the function of taking a talk on a PTT communication channel, then releasing the channel; a short press of a button (physical or virtual), or a sequence of presses of one or more buttons (physical and / or virtual), for example to trigger an alert such as sending an "SOS"; a short press of a button (physical or virtual), or a sequence of presses of one or more buttons (physical and / or virtual), for example to switch from one communication channel to another (a function commonly called "switch").the detection and adaptation to the properties relating to the management of audio and / or video streams specific to terminal 1, in particular the latencies arising from the hardware configuration of terminal 1 which are critical parameters in real-time communications.

[0048] The examples refer to a button. However, interface variations are possible, such as gestures performed on a touchscreen.

[0049] If the user validates the temporary configuration file (“OK”) by an action via the human-machine interface of terminal 1, the update process can continue, for example by implementing operation 109 described below.

[0050] If, on the other hand, the user does not validate the temporary file, either through a specific action or by remaining inactive for a predetermined period, a "KO" signal for the configuration file can be sent from terminal 1 to server 2. Preferably, the KO signal is accompanied by data from tests performed by the user in test mode. Such data might include, for example: associations between commands from the hardware layer of terminal 1 and the expected behavior of the application; and / or a modified configuration file (partial or complete) determined by the back end of the application itself.

[0051] Depending on the nature of the corrective data transmitted by terminal 1 to server 2, a corrected configuration file can be generated automatically (by implementing a corrective module on server 2 without human intervention), or it can be created by a human operator accessing the corrective data received on server 2.

[0052] The corrected configuration file remains marked "temporary" (referenced D' x,y ,Z" in [ Fig. 3 ]) and perhaps: sent back to terminal 1 to repeat the tests to confirm its validity; and / or added to database 3, replacing the previous version of the configuration file, so that it is accessible at least to terminal 1, and optionally to other terminals. In the example described here, the corrected configuration file remains marked "temporary" until manually validated by an operator. Other validation rules can be implemented, for example, validation by a minimum number of users.

[0053] Operation 109 includes: e. In response to a predetermined validation action by the user via terminal 1, remove an indicator qualifying the file as temporary on terminal 1. In other words, the configuration file becomes definitive / final at the initiative of the user of terminal 1.

[0054] Operation 110 involves switching the front-end application to normal mode. In other words, the temporary test mode is deactivated. The application then returns to normal, operational function.

[0055] An operation 111 includes: transmitting, from terminal 1 to server 2, a command to validate said temporary configuration file.

[0056] It should be noted that operations 109, 110 and 111 are independent and can therefore be implemented in parallel with each other or one after the other in any order.

[0057] An operation 112 includes: f. upon receipt on server 2 from terminal 1 of the command to validate the temporary configuration file (following the implementation of operation 111 for example), removing an indicator qualifying the file as temporary in the corresponding association B 1 , C 1 , D x,y , Z of database 3. Operation 112 can correspond to making the association and the corresponding configuration file available to the other terminals 1 from server 2. In the example described here, operation 112 marks the end of the configuration update process. Industrial application

[0058] The update processes were presented as implemented by terminal 1 and server 2. It will be understood that the processes can take the form of computer programs containing instructions for implementing the processes when these programs are executed by a processor, respectively of terminal 1 or server 2. We will also consider non-transient recording media readable by a computer on which programs are recorded for implementing the processes described here when these programs are executed by a processor.

[0059] These technical solutions can be applied particularly in the context of maintaining application programs for a computer system, commonly referred to as "applications". They are especially advantageous when applied to call-to-call communication applications via mobile phone networks, notably because of the wide variety of firmware versions of mobile terminals in circulation, and also because the interactions between the user and their terminal in this area are specific (for example, pressing and releasing a button to answer and then release a call on a communication channel).

[0060] This disclosure is not limited to the examples of systems, terminals, servers, processes, programs and program media described above, which are only examples, but encompasses all the variations that a person skilled in the art may consider in the context of the protection sought. List of reference signs

[0061] 1: Terminal 2: Server 3: Database 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112: operations I: List II: Lookup Table A: Terminal ID B: Hardware Layer ID C: Operating System ID D: Configuration File Z: Temporary File Marker.

Claims

1. A system comprising at least a terminal (1) and a server (2) capable of communicating with each other, characterised in that the system further comprises a back-end application and a corresponding front-end application respectively installed on the server and the terminal, the server having access to at least one database (3) comprising: - a list (I) of sets of identifiers, each set of identifiers comprising * a terminal identifier (A), * a hardware layer identifier (B), and * an operating system identifier (C); - a correspondence table (II) between * each hardware layer and operating system identifier pair (Bx; Cy) existing in said list (I), and * a configuration file (Dx,y), itself stored in the at least one database, the terminal and the server being configured in coordination with each other for, on opening a communication session between the terminal and the server: a. transmitting (101), from the terminal to the server, a set of identifiers comprising an identifier (A1) of the terminal, an identifier (B1) of a hardware layer of the terminal, and an identifier (C1) of the operating system implemented on the terminal; b. on receipt on the server, from the terminal, of the set of identifiers (A1, B1, C1), comparing (102) to the contents of the database, and - in the event of a match between the set of identifiers (A1, B1, C1) transmitted and a set of identifiers of said list (I), continuing the communication session without updating the terminal configuration; - in the event of no match between the set of identifiers (A1, B1, C1) transmitted and the sets of identifiers of said list (I), and in the event of a match with a hardware layer and operating system identifier pair (B1, C1) of the correspondence table (II), transmitting (103) in return, from the server to the terminal, the configuration file (D1,1) associated with said pair (B1, C1) according to the correspondence table; - in the event of no match with a hardware layer and operating system identifier pair (Bx, Cy) of the correspondence table (II), identifying (104), in the correspondence table (II) and by applying predefined rules, a hardware layer and operating system identifier pair (Bx, Cy) closest to that of the set of identifiers (B1, C1) transmitted from the terminal, then transmitting (105) in return, from the server to the terminal, the configuration file (Dx,y) associated with the identified combination (Bx, Cy) according to the correspondence table (II), said file being transmitted with an indicator (Z) qualifying the configuration file (Dx,y, Z) as temporary; c. feeding (106) the database with the set of identifiers (A1, B1, C1) received and any association resulting from the identification (B1, C1, Dx,y, Z) d. on receipt of a configuration file (D1,1; Dx,y, Z) on the terminal from the server, implementing (107) said configuration file in the front-end application, and if and only if said configuration file contains an indicator (Z) qualifying the file as temporary, switching (108) the front-end application to a test mode.

2. The system according to claim 1, wherein the terminal and the server are furthermore configured for: e. in response to a predetermined validation action by the user via the terminal, deleting (109) an indicator (Z) qualifying the file as temporary on the terminal, switching (110) the front-end application to a normal mode, transmitting (111), from the terminal to the server, a validation command of said temporary configuration file f. on receipt on the server, from the terminal, of the validation command of the temporary configuration file on the server, deleting (112) an indicator (Z) qualifying the temporary file in the corresponding association (B1, C1, Dx,y, Z) of the database.

3. A configuration method implemented by a terminal (1) capable of communicating with a server (2), characterised in that a back-end application and a corresponding front-end application are respectively installed on the server and the terminal, the server having access to at least one database (3) comprising: - a list (I) of sets of identifiers, each set of identifiers comprising * a terminal identifier (A), * a hardware layer identifier (B), and * an operating system identifier (C); - a correspondence table (II) between * each hardware layer and operating system identifier pair (Bx; Cy) existing in said list (I), and * a configuration file (Dx,y), itself stored in the at least one database, the method comprising, on opening a communication session between the terminal and the server: a. transmitting (101), from the terminal to the server, a set of identifiers comprising an identifier (A1) of the terminal, an identifier (B1) of a hardware layer of the terminal, and an identifier (C1) of the operating system implemented on the terminal; d. on receipt of a configuration file (D1,1; Dx,y, Z) on the terminal from the server, implementing (107) said configuration file in the front-end application, and if and only if said configuration file contains an indicator (Z) qualifying the file as temporary, switching (108) the front-end application to a test mode.

4. The method according to claim 3, further comprising: e. in response to a predetermined validation action by the user via the terminal, deleting (109) an indicator (Z) qualifying the file as temporary on the terminal, switching (110) the front-end application to a normal mode, transmitting (111), from the terminal to the server, a validation command of said temporary configuration file.

5. A configuration method implemented by a server (2) capable of communicating with at least one terminal (1), characterised in that a back-end application and a corresponding front-end application are respectively installed on the server and the terminal, the server having access to at least one database (3) comprising: - a list (I) of sets of identifiers, each set of identifiers comprising * a terminal identifier (A), * a hardware layer identifier (B), and * an operating system identifier (C); - a correspondence table (II) between * each hardware layer and operating system identifier pair (Bx; Cy) existing in said list (I), and * a configuration file (Dx,y), itself stored in the at least one database, the method comprising, on opening a communication session between the terminal and the server: b. on receipt on the server, from the terminal, of a set of identifiers (A1, B1, C1), comparing (102) to the contents of the database, and - in the event of a match between the set of identifiers (A1, B1, C1) transmitted and a set of identifiers of said list (I), continuing the communication session without updating the terminal configuration; - in the event of no match between the set of identifiers (A1, B1, C1) transmitted and the sets of identifiers of said list (I), and in the event of a match with a hardware layer and operating system identifier pair (B1, C1) of the correspondence table (II), transmitting (103) in return, from the server to the terminal, the configuration file (D1,1) associated with said pair (B1, C1) according to the correspondence table; - in the event of no match with a hardware layer and operating system identifier pair (Bx, Cy) of the correspondence table (II), identifying (104), in the correspondence table (II) and by applying predefined rules, a hardware layer and operating system identifier pair (Bx, Cy) closest to that of the set of identifiers (B1, C1) transmitted from the terminal, then transmitting (105) in return, from the server to the terminal, the configuration file (Dx,y) associated with the identified combination (Bx, Cy) according to the correspondence table (II), said file being transmitted with an indicator (Z) qualifying the configuration file (Dx,y, Z) as temporary; c. feeding (106) the database with the set of identifiers (A1, B1, C1) received and any association resulting from the identification (B1, C1, Dx,y, Z).

6. The method according to claim 5, further comprising: f. on receipt on the server, from the terminal, of a validation command of the temporary configuration file on the server, deleting (112) an indicator (Z) qualifying the temporary file in the corresponding association (B1, C1, Dx,y, Z) of the database.

7. A terminal (1) configured for implementing a method according to one of claims 3 to 4.

8. A server (2) configured for implementing a method according to one of claims 5 to 6.

9. A computer program comprising instructions for implementing the method according to one of claims 3 to 6, when this program is executed by a processor.

10. A non-transitory computer-readable recording medium having a program recorded thereon for implementing the method according to one of claims 3 to 6, when this program is executed by a processor.